决战圣地玛丽乔亚Day27

磁盘预读机制：

mysql有时会有这样的操作场景，就是对某个大数据量的表进行全表扫描。那么此时会将buffer pool中的缓存页全部淘汰掉，存进这些全表扫描的数据。那么当下一波热点数据的请求进来的时候，就又需要从磁盘去读取数据到缓存页中，会导致IO开销增加。

所以MYSQL对LRU进行了改造，分为冷/热两部分LRU链表。当新的数据要拉进缓存但是缓存页的数据满了的时候，就先开始淘汰冷链中的页数据。当冷链中的数据在1秒内被再次访问的时候，不会放到热链中去，只有在1秒之后被再次访问了，才会放到热链的头部去。

show variables like 'innodb_old_blocks_time'; 冷链数据多少秒后再次被使用转为热数据。

 

预读就是当从磁盘上读取一个页的时候，把相邻的其他页也读进来。

这种机制带来的好处：可以节省磁盘io的时间，直接从内存中读取数据。

触发条件：

顺序访问了磁盘上一个区的多个数据页，当这个数量超过56（默认的阈值）的时候，innodb会触发预读机制

show variables like 'innodb_read_ahead_threshold';

 

# buffer pool大小 show variables like 'innodb_buffer_pool_size';

# buffer pool实例个数 show variables like 'innodb_buffer_pool_instances';

查看总体数据：

show engine innodb status;

 

什么是MRR？参数的作用？

 

事务方面：

ACID相关：

持久性和一致性的区别？

持久性：指事务结束后，对数据的修改是永久的，不会回滚到之前的状态。事务一旦提交，其结果永久性写入磁盘，即使宕机等数据库也可以恢复。

一致性：一致性代表底层数据存储的完整性。业务逻辑不会导致数据的不一致。它必须由事务系统和应用开发人员共同来保证。事务系统通过保证事务的原子性，隔离性和持久性来满足这一要求;

应用开发人员则需要保证数据库有适当的约束(主键，引用完整性等)，并且工作单元中所实现的业务逻辑不会导致数据的不一致(即，数据预期所表达的现实业务情况不相一致)

与CAP的一致性的区别？

在存储系统中，为了避免数据丢失，我们都会对数据进行持久化。对数据进行持久化可以避免宕机带来的数据丢失问题，但是不能解决单机永久性故障的问题。

存储系统作为基础设施，在单机上持久化是远远不够的，我们需要将数据复制到多台机器上以提升系统的可用性和可靠性。一旦数据被复制到多个节点，那么就产生了一致性的问题。

CAP的一致性：

强调进群节点中数据一致。在分布式中一致性又包括强一致性和弱一致性，强一致性就是指在任何时刻任何节点看到的数据都是一样的；

弱一致性一般实现是最终一致性，即刚开始可能存在差异，但随着时间的推移，最终数据保持一致。

ACID的一致性：

指事务开始之前和事务结束之后，数据的完整性约束没有被破坏。

包含两层含义：

a)数据库机制层面，事务执行前后，数据能符合设置的约束，如唯一约束、外键约束；

b)业务层面，由应用开发人员保证业务一致性。还是以银行转账为例，A、B两个账号，转账之前和之后，A、B两个账号余额总额必须一致。

 

原子性含义？

一个事务的所有操作，要么全部完成，要么全部不完成。

所谓事务，是指由一系列数据操作所组成的完整逻辑过程。比如银行转账事务由两个操作组成：从源账户扣除金额，以及向目标账户增加金额。

持久性如何实现？

redolog的实现。

当事务提交时，必须先将事务的所有日志写入日志文件进行持久化，就是我们常说的WAL（write ahead log）机制（这个技术是保障持久性的关键技术，在HBase中也扮演重要角色，有兴趣的同学可以参考xxxxx）。这样才能保证断电或宕机等情况发生后，已提交的事务不会丢失，这个能力称为 crash-safe。

代码控制（redolog、binlog、undolog）

redolog：
binlog：

undolog：