Change Buffer 是 InnoDB 中用于缓存非唯一二级索引页变更的内存结构，仅在对应页未加载时生效，通过延迟合并（访问页、后台线程、淘汰前、关闭前）减少随机 I/O，提升写性能。
MySQL 的 Change Buffer（变更缓冲区）是 InnoDB 存储引擎中用于优化非唯一二级索引（Secondary Index）写入性能的重要机制，它不是“合并机制”本身，而是为后续的 异步合并（Merge） 做准备的临时缓存结构。
Change Buffer 是什么？
当对一张表执行 INSERT、UPDATE 或 DELETE 操作时，如果涉及的二级索引页（B+ 树叶子节点）当前不在 Buffer Pool（内存缓存）中，InnoDB 不会立即将磁盘上的索引页读入内存再修改，而是把这次变更记录到 Change Buffer 中——一个位于 Buffer Pool 内的特殊区域（逻辑上属于 Buffer Pool，但物理上可独立管理）。
它只适用于满足以下条件的操作：
- 目标索引是非唯一的二级索引（唯一索引和主键索引不适用，因为需立即校验唯一性）
- 对应索引页未被加载进 Buffer Pool（否则直接更新内存页更高效）
- 操作类型为 insert、update（非唯一字段）、delete（标记删除）
Change Buffer 如何触发合并（Merge）？
Merge 不是定时或主动发起的“合并任务”，而是在特定访问场景下被动触发的延迟处理过程。核心触发时机包括：
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 访问目标索引页时：下次查询或写入需要读取该索引页（例如 SELECT 走该索引、或后续 DML 需要修改同一页），InnoDB 会先将 Change Buffer 中所有关于该页的变更合并进内存页，再继续处理
- 后台线程定期合并：InnoDB 后台线程（如 master thread 和 page cleaner thread）会在系统空闲时，按一定策略（如页访问热度、脏页比例）将部分 Change Buffer 记录合并到对应的索引页
- Buffer Pool 淘汰前：若某索引页即将被驱逐出 Buffer Pool，而它有未合并的 Change Buffer 条目，InnoDB 会强制合并，避免丢失变更
- 实例关闭前：shutdown 过程中会将剩余 Change Buffer 全量 merge 到磁盘索引页，确保数据持久化
为什么不用每次都直接读页？
本质是用空间换时间，缓解随机 I/O 压力：
- 二级索引通常分散、无序，随机读取索引页代价高（尤其是机械盘或高并发场景）
- Change Buffer 把多次离散的索引更新，攒成一次顺序/局部合并操作，显著降低 I/O 次数
- 合并后还能配合刷脏（flush）机制，让多个变更一起落盘，提升写吞吐
注意：Change Buffer 太大会占用 Buffer Pool 空间，影响其他数据页缓存；可通过 innodb_change_buffer_max_size 参数限制其最大占比（默认 25%，即最多占 Buffer Pool 的 1/4）。
如何观察和调优？
可通过以下方式确认 Change Buffer 工作状态：
- 查看状态变量：
SHOW STATUS LIKE 'Innodb_ibuf%';关注Innodb_ibuf_size（当前大小）、Innodb_ibuf_merges（总合并次数）、Innodb_ibuf_merge_inserts/upd/delete_marks（各类 merge 数量） - 分析慢日志或 Performance Schema，识别是否因频繁 merge 导致延迟尖刺
- 写密集且二级索引多的场景（如日志表、消息队列表），适当增大
innodb_change_buffer_max_size可提升写入吞吐；但 OLTP 主键查询多的业务，应保持默认或略降，避免挤占热数据缓存
它不改变 SQL 语义，也不影响事务一致性——所有变更在 merge 前仍受 undo log 和 redo log 保护，崩溃恢复时可通过 redo 重放 Change Buffer 内容。
