MySQL Change Buffer设计分析

Change Buffer的由来？

我们应该知道MySQL为了提升数据读取的效率，会将从磁盘中读取的数据放入内存中的一个名为缓冲池的数据结构中，这样下次再查询时，如果数据在缓冲池中，就可以直接返回了，从而减少了一次随机的磁盘IO。

缓冲池解决了数据查询每次都要从磁盘查找的问题，但是并不能解决数据更新或者插入的问题，当需要更新一条数据时，按道理应该需要先把数据从磁盘读取到缓冲池中，然后再更新缓冲池中的数据页，最后再写回磁盘，这样就会产生两次磁盘IO的操作，所以为了解决多次磁盘IO的问题，MySQL就设计出了Change Buffer来减少磁盘IO的次数。

Change Buffer如何解决磁盘IO的问题

有了Change Buffer以后，如果当前更新的数据页不在缓冲池中，那么数据就会被先记录在Change Buffer中，然后等到未来发生数据读取时，再把Change Buffer中的记录合并到缓冲池中，这样一来就减少了一次先从磁盘读取数据到缓冲池的IO消耗。

一般来说，当未来读取到数据页时，Change Buffer中已经有涉及到这个数据页的一批更新记录了，这样一次磁盘读取数据页的操作，就能实现一批记录的更新，相比原来一次更新就需要一次磁盘读取要减少了很多，现在相当于多次更新只对应一次磁盘读取。

Change Buffer只支持普通索引

需要注意的是Change Buffer只能支持普通索引，像唯一索引这样需要判断数据唯一性的场景是不适用的，如果直接写Change Buffer就结束，那就无法判断唯一性了，所以既然无论如何都要从磁盘读取数据到缓冲池中，那就没有必要再多写一次Change Buffer了。

Change Buffer什么时候合并到缓冲池?

• 1、当访问数据页时，会触发Change Buffer合并到缓冲池中，然后更新Change Buffer记录的相关操作到缓冲池的数据页中。
• 2、后台定时触发Change Buffer合并。

什么时候应该使用Change Buffer？

当普通索引上存在大量的DML操作时，并且写完之后不会立刻查询，也就是写多读少的情况下，应该考虑到Change Buffer带来的好处。

什么时候不应该使用Change Buffer？

如果表中的普通索引较少，而唯一索引较多，又或者写完之后又立刻会读，那就会触发合并，就不能达到减少磁盘IO的目的，并且反而会多一次写Change Buffer带来的消耗。如果确定业务场景不适用于Change Buffer，建议通过压测的方式进行证明。

Change Buffer的大小

Change Buffer的大小是受限于缓冲池的大小的，可以通过innodb_change_buffer_max_size参数配置，默认25，表示Change Buffer占缓冲池大小的25%，改值最大为50%。

Change Buffer配置

通过innodb_change_buffering配置可以控制哪些操作使用Change Buffer，哪些操作不使用Change Buffer。

• all

默认值：缓冲区插入、删除标记操作和清除。

• none

不要缓冲任何操作。

• inserts

缓冲区插入操作。

• deletes

缓冲区删除标记操作。

• changes

缓冲插入和删除标记操作。

• purges

在后台发生的缓冲区物理删除操作。