MySQL写缓存Change Buffer原理与架构师必备技能详解

作为一种存储系统，MySQL同样配备了缓冲池（buffer pool）机制，旨在避免每次数据查询都触发磁盘IO操作。对于使用MySQL的开发者而言，深入理解InnoDB缓冲池的工作原理是架构师必备的知识。

在之前的《MySQL缓冲池（buffer pool）》一文中，我们详细介绍了InnoDB缓冲池的工作机制。

有一位名为童鞋的读者在评论区提问：对于读请求，MySQL缓冲池能够显著减少磁盘IO，提升系统性能。那么对于写请求，MySQL又是如何进行优化的呢？今天我们就来深入探讨这个问题。

首先，让我们简要回顾上一讲提到的缓冲池核心概念：

MySQL的数据存储包含内存与磁盘两个部分；内存缓冲池（buffer pool）以页为单位，缓存最热的数据页（data page）与索引页（index page）；InnoDB采用改进版LRU算法管理缓冲池，能够有效应对“预读失效”与“缓冲池污染”的问题；

当写请求到来时，会发生什么？

情况一

假设需要修改页码为4的索引页，而这个页面恰好在缓冲池内。

如上图步骤1-2所示：

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

这样的处理效率是最高的。

画外音：类似日志顺序写入的场景，每秒数万次操作都能轻松应对。

是否会引发数据一致性问题？

完全不会。

读取操作会命中缓冲池中的页面；当缓冲池进行LRU数据淘汰时，会将“脏页”刷回磁盘；即使数据库异常崩溃，也能通过redo log恢复数据；

缓冲池中的页面何时会被刷入磁盘？

采用定期刷盘机制，而非每次修改都立即刷盘，能够有效降低磁盘IO，显著提升MySQL性能。

画外音：批量写入是常见的优化手段。

情况二

假设需要修改页码为40的索引页，而这个页面当前不在缓冲池内。

此时流程会稍微复杂一些，如上图需要完成步骤1-3：

先将页码40的索引页从磁盘加载到缓冲池，这是一次磁盘随机读操作；修改缓冲池中的页面，这是一次内存操作；写入redo log，这是一次磁盘顺序写操作；

当写请求未能命中缓冲池时，至少会产生一次磁盘IO。对于写多读少的业务场景，是否存在进一步的优化空间呢？

这正是InnoDB设计者考虑的问题，也是本文将要讨论的写缓冲（change buffer）机制。

画外音：从命名就可以看出，写缓冲是通过降低磁盘IO来提升数据库写入性能的一种技术手段。

什么是InnoDB的写缓冲？

在MySQL 5.5版本之前，这个功能称为插入缓冲（insert buffer），仅对insert操作进行优化；现在该机制对delete和update同样有效，因此更名为写缓冲（change buffer）。

它是一种应用于非唯一普通索引页（non-unique secondary index page）不在缓冲池中时，对页面进行写操作的优化技术。该机制不会立即将磁盘页加载到缓冲池，而是仅仅记录缓冲变更（buffer changes），等到未来数据被读取时，再将数据合并（merge）恢复到缓冲池中的技术。写缓冲的核心目的是降低写操作的磁盘IO，提升数据库整体性能。

画外音：这个句子确实写得有点长。

引入写缓冲优化后的流程变化

假设需要修改页码为40的索引页，而这个页面正好不在缓冲池内。

加入写缓冲优化后，流程简化为：

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

此时性能表现与目标页面在缓冲池中时非常接近。

画外音：可以看到，40这个页面并没有被加载到缓冲池中。

此时是否会出现一致性问题？

同样不会。

即使数据库异常崩溃，也能从redo log中恢复数据；写缓冲不仅是一个内存结构，它也会被定期刷盘到写缓冲系统表空间；数据读取时，存在另外一个流程将数据合并到缓冲池；

不妨设想，稍后的某个时间，有请求需要查询索引页40的数据。

此时的流程如步骤1-3所示：

加载索引页面，缓冲池未命中，这次磁盘IO无法避免；从写缓冲读取相关信息；恢复索引页面，放到缓冲池LRU列表里；

画外音：可以看到，40这个页面只有在真正被读取时，才会被加载到缓冲池中。

还有一个遗留问题：为什么写缓冲优化仅适用于非唯一普通索引页？

在InnoDB中，聚集索引（clustered index）和普通索引（secondary index）存在本质差异，我们在之前的文章中已经详细讨论过，这里不再展开。

如果索引设置了唯一（unique）属性，在进行修改操作时，InnoDB必须进行唯一性检查。也就是说，即使索引页不在缓冲池中，磁盘上的页面读取也无法避免（否则如何校验是否唯一？），此时应该直接将要修改的页面放入缓冲池再进行变更，而不应该再使用写缓冲这个中间环节。

除了数据页被访问，还有哪些场景会触发写缓冲中的数据刷盘？

还存在以下几种情况，会促发写缓冲中的数据刷盘：

后台有一个专门的线程，会在数据库空闲时执行；当数据库缓冲池空间不足时；在数据库正常关闭时；当redo log写满时；

画外音：几乎不会出现redo log写满的情况，此时整个数据库将处于不可写入的不可用状态。

什么样的业务场景适合开启InnoDB的写缓冲机制？

先说说什么时候不适合，如上文分析，当：

数据库都是唯一索引；或者，在写入一个数据后，会立即读取它；

这两类场景在执行写操作时（进行后），本来就要进行页面读取，本来相应页面就要入缓冲池，此时写缓冲反倒成了负担，增加了复杂度。

什么时候适合使用写缓冲，比如：

数据库中大部分是非唯一索引；业务是写多读少，或者不是写后立即读取；

可以使用写缓冲，将原本每次写入都需要进行磁盘IO的SQL，优化为定期批量写磁盘。

画外音：例如，账单流水业务。

上述原理对应InnoDB中的哪些参数？

有两个比较重要的参数。

（1）参数：innodb_change_buffer_max_size

介绍：配置写缓冲的大小，占整个缓冲池的比例，默认值是25%，最大值是50%。

画外音：写多读少的业务，才需要调大这个值，读多写少的业务，25%其实也多了。

（2）参数：innodb_change_buffering

介绍：配置哪些写操作启用写缓冲，可以设置成all/none/inserts/deletes等。

写缓冲机制，你学明白了吗？

知其然，知其所以然。

思路比结论更重要。