在 MySQL 的 InnoDB 存储引擎中，change buffer 是一个容易被忽视却对性能影响巨大的内部机制。很多面试官喜欢问：“什么是 change buffer？它解决了什么问题？什么时候会触发 merge？”如果你只回答“它是缓冲非唯一二级索引的写入”，可能只能拿到及格分。下面我们从原理到实践，把 change buffer 彻底讲清楚。
一、为什么需要 change buffer？
InnoDB 的数据是按页（page）读写磁盘的，默认页大小 16KB。当执行一条 UPDATE 或 INSERT 语句时，如果目标数据页不在 Buffer Pool 中，InnoDB 需要先将该页从磁盘读入内存，修改后再写回。对于普通二级索引（非唯一索引）的修改，这个过程尤其昂贵：因为二级索引的更新往往分散在不同的页上，每次更新都可能触发一次随机磁盘读。
假设一张表有 10 个二级索引，执行一条 UPDATE 可能涉及多个索引页的修改。如果这些页都不在内存中，就要发生多次随机 I/O。在高并发写入场景下，这种开销会迅速拖垮数据库。
change buffer 正是为了解决这个问题而设计的。它的核心思想是：对于非唯一二级索引的修改操作，如果目标页不在 Buffer Pool 中，不立即从磁盘读取该页，而是将修改记录缓存在 change buffer 中。等未来某个时刻该页因为其他原因被读入内存时，再将缓存的修改合并（merge）到页上。这样就把多次随机写转换成了少量的顺序写，显著提升写入性能。
二、change buffer 到底缓存了什么？
change buffer 是一块位于 系统表空间（ibdata） 中的特殊区域，本质上是一棵 B+ 树，称为 ibuf tree。它缓存的是对非唯一二级索引页的物理修改操作，主要包括：
- INSERT：插入新的索引记录
- DELETE-MARK：删除标记（将记录标记为删除）
- DELETE：真正删除
注意几个关键限制：
- 只针对非唯一二级索引。唯一索引（包括主键）的修改必须立即检查唯一性约束，因此不能缓存。
- 只针对二级索引。聚簇索引（主键索引）的修改不会进入 change buffer。
- 只针对页不在 Buffer Pool 中的情况。如果目标页已经在内存里，直接修改内存页即可，不需要 change buffer。
三、change buffer 的合并时机
change buffer 中的修改不会永远滞留，最终必须合并到真正的索引页上。合并（merge）的触发时机主要有以下几种：
1. 访问该索引页时
这是最常见的合并时机。当某个查询或 DML 操作需要读取一个二级索引页时，如果该页在 change buffer 中有缓存的修改，InnoDB 会先将这些修改合并到页上，然后再将页返回给上层使用。这个过程称为 “读时合并”。
2. 后台线程定期合并
InnoDB 有一个专门的后台线程（ibuf merge thread），会周期性地扫描 change buffer，将其中缓存的修改合并到对应的索引页。这个线程在系统负载较低时更活跃，避免 change buffer 无限增长。
3. Buffer Pool 空间不足时
当 Buffer Pool 中的空闲页不足，需要淘汰一些页来腾出空间时，InnoDB 可能会触发 change buffer 的合并，以减少后续读取时的延迟。不过这个触发条件相对间接。
4. 数据库正常关闭时
在 MySQL 正常关闭（shutdown）时，InnoDB 会将 change buffer 中所有未合并的修改全部 merge 到索引页，保证数据一致性。如果异常崩溃，change buffer 中的内容可以通过 redo log 恢复。
5. change buffer 自身空间不足
change buffer 的大小由参数 innodb_change_buffer_max_size 控制，默认占 Buffer Pool 的 25%。当 change buffer 使用量接近上限时，会触发合并以释放空间。
四、关键参数与监控
与 change buffer 相关的重要参数：
innodb_change_buffering：控制哪些操作使用 change buffer，可选值包括none、inserts、deletes、changes、purges、all，默认all。innodb_change_buffer_max_size：change buffer 最大占 Buffer Pool 的百分比，默认 25，最大 50。
监控 change buffer 使用情况：
SHOW ENGINE INNODB STATUS\G
在输出中查找 INSERT BUFFER AND ADAPTIVE HASH INDEX 部分，可以看到：
size：当前 change buffer 大小free list len：空闲列表长度seg size：段大小merges：已合并次数merged operations：各类操作合并统计
如果 merges 增长缓慢而 size 持续增大，说明 change buffer 堆积严重，可能需要关注写入模式或调整参数。
五、适用场景与注意事项
change buffer 并非万能，它的收益取决于工作负载特征：
适合的场景：
- 写多读少，且更新分散在不同二级索引页上
- 非唯一二级索引较多
- 磁盘 I/O 成为瓶颈
不适合的场景：
- 更新后立即需要读取该索引（合并开销提前发生）
- 唯一索引占主导（无法使用 change buffer）
- 数据量小，Buffer Pool 能容纳全部热数据（页始终在内存中，change buffer 无用武之地）
另外，change buffer 会占用 Buffer Pool 空间，如果业务以读为主，可以适当调低 innodb_change_buffer_max_size，把更多内存留给数据页缓存。
六、面试常见追问
Q：为什么唯一索引不能用 change buffer？
A：唯一索引插入或更新时必须检查唯一性约束，这要求读取目标页确认是否已存在相同键值，因此无法延迟合并。
Q：change buffer 和 redo log 有什么区别？
A：redo log 记录的是物理页的修改，用于崩溃恢复；change buffer 缓存的是对二级索引页的修改操作，目的是减少随机 I/O。change buffer 中的修改本身也会写入 redo log，保证持久性。
Q：change buffer 会不会导致查询变慢？
A：如果查询恰好访问了 change buffer 中有缓存的页，需要先 merge 再返回，会增加一次延迟。但整体上，它通过减少随机 I/O 提升了系统吞吐。
总结
change buffer 是 InnoDB 针对非唯一二级索引写入的一种延迟合并优化。它把“立即随机读页并修改”变成“先记录修改，等页被读入时再合并”，从而将随机 I/O 转化为顺序 I/O。合并时机包括读页时、后台线程定期、Buffer Pool 空间不足、正常关闭以及自身空间不足。理解它的原理和边界，不仅能帮你应对面试，更能在实际调优中做出正确决策。
未经允许不得转载：任鹏个人博客 » MySQL 中的 change buffer 作用与合并时机
