MySQL Change Buffer 是 InnoDB 针对非唯一二级索引页不在 Buffer Pool 中时缓存 INSERT/DELETE/UPDATE 操作的机制，通过延迟合并减少随机 I/O；仅适用于非唯一二级索引，唯一索引因需即时校验约束而无法使用。
MySQL 通过 Change Buffer 把原本必须发生的随机磁盘读取，推迟到后续读操作或后台合并时才执行，从而跳过大量 I/O 开销——但仅对非唯一二级索引生效，且要求对应索引页不在 Buffer Pool 中。
Change Buffer 在 INSERT 过程中何时被触发
只有满足全部三个条件时，INSERT 才会写入 Change Buffer 而非直接更新索引页：
- 目标列上有
非唯一二级索引（例如INDEX status，而非UNIQUE INDEX email） - 该索引对应的 B+ 树页当前 不在 Buffer Pool 中（即缓存未命中）
-
innodb_change_buffering配置包含inserts（MySQL 8.0.20+ 默认可能是none，需确认）
不满足任一条件，InnoDB 就会走常规路径：先从磁盘加载索引页 → 修改页 → 写 redo log → 刷脏页。这一步在 HDD 环境下延迟明显，在 SSD 上差异缩小，但仍有可观测影响。
为什么唯一索引无法享受 Change Buffer 优化
插入时必须立刻检查唯一性约束，而校验动作依赖索引页中的现有键值。如果页不在内存里，InnoDB 不得不立即发起一次磁盘读取，把页加载进来再比对——这就失去了“延迟读”的前提。所以：UNIQUE INDEX、PRIMARY KEY（本质是聚簇索引）均绕过 Change Buffer。
常见误判场景：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 建了
UNIQUE INDEX (a, b)，但INSERT只给a赋值 → 仍需全键查重，无法缓冲 - 表有主键 + 唯一二级索引 + 普通二级索引 → 只有普通索引部分可能进 Change Buffer
Insert Buffer 合并（Merge）的真实触发时机
Change Buffer 不是“永久缓存”，它里面的变更最终必须落到真实索引页上。合并不是定时任务，而是被动触发的：
- 当某条查询语句（如
SELECT ... WHERE status = ?）需要访问那个被缓存修改过的索引页时，InnoDB 在把页载入 Buffer Pool 的瞬间完成 merge - 后台线程（
master thread或page cleaner thread）在系统空闲时主动合并部分缓存项 - 实例关闭前，所有未 merge 的 Change Buffer 内容会持久化到系统表空间，并在下次启动时回放
注意：SHOW STATUS LIKE 'Innodb_ibuf_merges_insert' 可查看 insert 类型 merge 总次数；SHOW ENGINE INNODB STATUS 里 “Ibuf” 小节能看到当前大小和 merge 状态。
实际调优中容易忽略的关键点
Change Buffer 是把双刃剑，盲目开启或配置不当反而拖慢性能：
-
innodb_change_buffer_max_size默认 25%，但在高并发写 + 大 Buffer Pool 场景下，可能吃掉过多内存，挤压热数据缓存空间 - MySQL 8.4+ 默认
innodb_change_buffering = none，如果你从老版本升级，要手动设回inserts才能启用 - 监控发现
Innodb_ibuf_merges暴涨 +Innodb_buffer_pool_wait_free升高，说明 merge 压力大，可能引发查询延迟毛刺 - 批量导入（
LOAD DATA/INSERT ... VALUES (),(),...）时，Change Buffer 效果最显著；单行插入几乎无收益
真正起作用的从来不是“开了没开”，而是“哪些索引页常驻内存、哪些长期离线、以及你的 workload 是否以写为主”。
