Change Buffer不是缓存数据页，而是缓存非唯一二级索引的变更操作；它仅存储INSERT、UPDATE、DELETE对未在Buffer Pool中的非唯一二级索引页的物理修改记录，待页被加载时合并，不适用于唯一索引。
Change Buffer不是缓存数据页，而是缓存非唯一索引的变更操作
Change Buffer 和 Buffer Pool 完全不是一回事。它不存数据页本身，只存对**非唯一二级索引页**的 DML 操作（INSERT、UPDATE、DELETE）的物理变更记录。前提是：目标索引页当前**不在 Buffer Pool 中**。一旦页被加载进内存，InnoDB 就会立刻把 Change Buffer 里对应的变更合并（Merge）进去，而不是“延迟写入该页”——它压根没打算写那个页，只是先记下“等你来时再改你”。
哪些操作能进 Change Buffer？看索引类型和语句类型
只有满足全部条件的操作才会被写入 Change Buffer：
-
UPDATE或DELETE针对的是**非唯一二级索引**（即普通索引，不含PRIMARY KEY或UNIQUE约束） - 对应的数据页当前未在 Buffer Pool 中（
SELECT触发加载后，后续变更就不再走 Change Buffer） - 语句不涉及聚簇索引（主键）更新——主键更新必须立即加载页并修改，无法延迟
-
INSERT只有在插入新索引项、且目标页不在内存时才进 Change Buffer；如果只是更新已有索引项值，仍需先加载页
常见误区：UPDATE t SET name='x' WHERE id=123（id 是主键）——这个操作完全绕过 Change Buffer，哪怕 name 字段上有普通索引，也只影响聚簇索引页，不触发 Change Buffer。
Change Buffer 的刷盘时机不是“定期”，而是被动触发
Change Buffer 本身是 Buffer Pool 内的一块内存区域（默认占 Buffer Pool 的 1/4，由 innodb_change_buffer_max_size 控制），它的内容不会像 redo log 那样按秒或事务提交刷盘。它的持久化依赖于两个机制：
- 当对应的数据页被其他查询主动加载进 Buffer Pool 时，InnoDB 在合并变更的同时，会把这次
Merge操作记入redo log—— 这才是真正的落盘保障 - 后台线程（
page cleaner）在刷脏页时，若发现某脏页的变更来自 Change Buffer 合并，也会顺带将 Change Buffer 中已合并的部分清理掉；未合并的条目则继续留在内存中等待下次加载 - MySQL 正常关闭前，会强制把所有未合并的 Change Buffer 条目写入系统表空间的
ibdata1中的 Change Buffer 段，确保重启后可恢复
注意：innodb_change_buffering 参数控制是否启用（all/none/inserts 等），但即使设为 none，某些场景（如崩溃恢复）仍可能临时使用，不能完全禁用底层逻辑。
为什么 Change Buffer 不适用于唯一索引？校验必须实时
唯一性约束要求每次 INSERT 或 UPDATE 都必须检查目标值是否已存在。如果把变更缓存在 Change Buffer 里，就无法执行这个检查——因为要查的页可能根本不在内存中。所以 InnoDB 对唯一索引的变更一律强制加载对应页，直接在内存中完成查重+修改，绕过 Change Buffer。这也是你调优时最容易忽略的点：加了唯一索引，等于自动关掉了该字段上所有写操作的 Change Buffer 优化。
Change Buffer 的价值不在“减少写次数”，而在避免为了一次小更新，把整个几 KB 的索引页从磁盘读上来又刷回去。但它高度依赖访问模式：如果某索引页长期不被查询，Change Buffer 条目就一直堆积在内存里，直到刷脏页或重启才落地——这时候它反而成了内存开销和恢复负担。真正起效的前提，是“写多读少，且读操作最终会触发页加载”。
