一文了解MySQL写缓冲Change Buffer（定义作用执行过程触发时机业务场景）

MySQL的数据存储包含内存与磁盘两个部分，内存缓冲区buffer pool以页为单位，缓存最热的数据页data page与索引页index page，InnoDB以变种LRU算法管理缓冲池，并且解决了预读失效和缓冲池污染的问题。对于读请求，缓冲池可以减少磁盘IO，提升性能，那么写请求呢？

思考2个场景：

场景1：假设要修改页号为4的索引页，这个页恰好在缓冲池里，那么修改的步骤为：

直接修改缓冲池的页，一次内存操作
写入redo log，一次磁盘顺序写操作

这样效率高，而且写日志这种顺序写，每秒可以支持上万的并发量

一致性问题也不会出现，如果读取的时候，命中缓冲池的页；缓冲池通过LRU后淘汰了数据，会将正确数据刷回磁盘；数据库异常崩溃，redo log里恢复的数据也没问题。

那么缓冲池的页什么时候会刷到磁盘上呢？定期刷磁盘，通过批量写的方式降低磁盘IO

场景2：修改页号为100的索引页，这个页不在缓冲池里，修改的步骤为：

先把序号为100的索引页从磁盘加入到缓冲池里，一次磁盘随机读操作
修改缓冲池的页，一次内存操作
写入redo log，一次磁盘顺序写操作

没有命中缓冲池的时候，至少产生一次磁盘IO，对于写多读少的业务场景，还有优化的空间，也就是写缓冲 change buffer，是降低磁盘IO，提升数据库写性能的一种机制。

定义和作用

写缓冲Change Buffer是InnoDB为了提高非主键索引操作性能而引入的一种机制。当对非唯一索引进行更改（如插入、更新、删除操作）时，如果对应的数据页不在缓冲池（Buffer Pool）中，InnoDB不会立即从磁盘读取数据页，而是将这些更改操作缓存到Change Buffer中，等未来数据被读取时，再将数据合并merge恢复到缓冲池中。这样做的目的是为了减少对磁盘的I/O操作，从而提高数据库的整体性能。

执行过程

还是以刚刚的场景2为例，修改页号为100的索引页，这个页不在缓冲池里，加入写缓冲后修改的步骤为：

在写缓冲里记录这个操作，一次内存操作
写入redo log，一次磁盘顺序写操作

性能与场景1相近

对于数据一致性问题，也不会出现。数据库异常崩溃的时候，可以从redo log里恢复数据；写缓冲也会被定期刷盘到写缓冲系统表空间；数据读取的时候，将数据合并到缓冲池。

当稍后有请求查询索引页100的数据时，流程如下：

缓冲池未命中，从磁盘里载入索引页
从写缓冲读取相关信息
恢复索引页，放入缓冲池

整个写缓冲的执行过程可以总结如下：

更改暂存：非主键索引的记录被更新或删除时，这些更改操作首先被暂存到Change Buffer中
合并更改：当数据页从磁盘上读取到内存中时，Change Buffer中的相关信息会被用来合并这些更改，即应用到对应的缓存数据页中。
刷新到磁盘：Change Buffer中的更改操作最终会被刷新到磁盘上，以保持数据的一致性。
清理过程：InnoDB会定期执行清理过程，移除那些已经过时或不再需要的更改操作信息。

触发时机

非主键索引的更新操作：当一个非主键索引的记录被更新时，Change Buffer会触发并将更改操作暂存到内存中
非主键索引的删除操作：当一个非主键索引的记录被删除时，Change Buffer同样会触发并将该删除操作暂存到内存中。
数据页读取操作：当从非主键索引页读取数据时，Change Buffer会检查该页是否在Change Buffer中有相关的更改。如果有，它会将这些更改应用到该页上，确保读取的数据是最新的。

思考一个问题：为什么写缓冲优化，只适用于二级索引？

如果索引设置了唯一unique属性，在修改操作时，InnnoDB必须进行唯一性检查。索引页即使不在缓冲池里，磁盘上的页读取也是要进行的，因为要检验是否唯一，这里就会把相应的页直接放入缓冲池再修改，无需写缓冲。