MySQL：change buffer

1、change buffer

         InnoDB的数据是按数据页为单位来读写的。也就是说，当需要读一条记录的时候，并不是将这个记录本身从磁盘读出来，而是以页为单位，将其整体读入内存。在InnoDB中，每个数据页的大小默认是16KB。

        在更新数据页时，首先去内存中查看是否有这个数据页，如果在内存中有，就直接更新；如果内存中没有这个数据页的话，InnoDB就会将这些更新操作缓存在change buffer中，这样就不需要从磁盘中读取这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。

可持久化

        change buffer也是可以持久化的，change buffer在内存中有拷贝，也会被写入磁盘中。将change buffer中的操作应用到原数据页，得到最新结果的过程称为merge。触发持久化merge的操作：

1、访问这个数据页会触发merge外

2、系统有后台线程会定期merge进行持久化

3、在数据库正常关闭（shutdown）的过程中，也会执行merge操作。

如果能够将更新操作先记录在change buffer，减少读磁盘，语句的执行速度会得到明显的提升。

1、change buffer对唯一索引和普通索引性能的影响

唯一索引

        唯一索引不使用change buffer。唯一索引在执行更新操作时，要先判断是否符合唯一约束条件，那么在插入数据时会先从表中读取数据到内存中，然后判断是否符合唯一约束条件。所以唯一索引插入时肯定内存中会有这个数据页，即使没有也会查询磁盘数据保存到内存。所以内存中有数据页，直接更新即可，不需要保存到change buffer中。

普通索引

        普通索引使用change buffer，如果我们往表中插入一条新数据，InnoDB的流程分为两种情况：

第一种，需要更新的数据页在内存中，流程如下：

a) 对于唯一索引，直接更新内存，插入数据；

b) 对于普通索引，判断内存中是否有目标数据页，如果有，直接更新内存，插入数据；

普通索引只比唯一索引多了一个判断，不会消耗太多的CPU时间。

第二种，需要更新的数据页不在内存中，流程入下：

a) 对于唯一索引，为保证数据唯一，首先查询需要更新的数据页，保存到内存中，直接更新内存；

b) 对于普通索引，内存中没有，将更新记录在change buffer中，语句执行就结束了，少了读取磁盘的一步；

小结：

        将数据从磁盘读入内存涉及随机IO的访问，是数据库里面成本最高的操作之一。change buffer因为减少了随机磁盘访问，所以对更新性能的提升是会很明显的。

3、change buffer的使用场景

        通过上面的分析，已经清楚了在普通索引的场景下，使用change buffer对更新过程的加速作用。下面说一下普通索引场景下change buffer的使用场景：

        因为merge的时候是真正进行数据更新的时刻，而change buffer的主要目的就是将记录的变更动作缓存下来，所以在一个数据页做merge之前，change buffer记录的变更越多（也就是这个页面上要更新的次数越多），收益就越大。

        因此，对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时change buffer的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。

        反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在change buffer，但之后由于马上要访问这个数据页，会立即触发merge过程。这样随机访问IO的次数不会减少，反而增加了change buffer的维护代价。所以，对于这种业务模式来说，change buffer反而起到了副作用。