change buffer 是 innodb 独有、myisam 完全不支持的写优化机制，仅对非唯一二级索引且对应页不在 buffer pool 时生效，通过延迟合并变更减少随机 i/o，但会增加 cpu 开销与内存占用。
Change Buffer 是 InnoDB 独有的写优化机制，MyISAM 根本没有这个东西 —— 所以不是“相比有何优势”，而是“MyISAM 压根不具备这项能力”。
为什么 MyISAM 完全不支持 Change Buffer
MyISAM 没有缓冲池（buffer pool）概念，也不维护内存中的索引页状态。它对索引的修改（如 INSERT、UPDATE）必须立即写入磁盘的 .MYI 文件，且是随机 I/O。没有“页是否在内存中”的判断前提，自然也就没有“缓存变更再合并”的逻辑基础。
- MyISAM 的
key_buffer_size只缓存索引块，但不跟踪这些块是否“脏”、是否需要延迟合并 - 所有写操作都直接落盘，无法区分“页在内存”和“页不在内存”两种路径
- 没有 redo log、没有页级锁、没有崩溃恢复需求，也就不需要 change buffer 这类与 crash-safe 强耦合的结构
InnoDB 的 Change Buffer 在什么场景下真正起效
Change Buffer 不是总开启、也不是对所有索引都生效。它只在满足以下全部条件时才介入：
- 操作目标是
非唯一二级索引（即没加UNIQUE或PRIMARY KEY的索引） - 该索引对应的数据页当前 不在 buffer pool 中（即要更新的索引页未被缓存）
-
innodb_change_buffering配置允许对应操作类型（默认为all，含insert、delete-mark、purge） - 该索引页不是根页（Change Buffer 只缓存叶页变更）
典型有效场景：大批量导入订单数据到一张带普通 status 或 created_at 索引的表，而这些索引页尚未加载进内存。
实际性能差异体现在 I/O 模式上
对比一次对非唯一二级索引的 INSERT：
- MyISAM：必须读取对应
.MYI页 → 修改 → 写回磁盘（两次随机 I/O：一次读、一次写） - InnoDB（页不在 buffer pool）：只写入
change buffer（内存操作）+ 记一条redo log（顺序写）→ 合并延后到页被读入时或后台线程触发 - InnoDB（页已在 buffer pool）：直接修改索引页 + 记
redo log，不走 change buffer
关键点：change buffer 把原本可能发生的多次随机写，压缩成一次顺序 redo log 写入，并把物理索引页更新推迟到更可控的时机（比如读请求触发、后台合并线程）。这对高并发写入、SSD 耐久性、以及突发性批量导入都有明显收益。
容易被忽略的代价和限制
Change Buffer 不是免费午餐。它带来的隐性成本常被低估：
- 合并（merge）本身消耗 CPU：当一个被缓存变更的索引页终于被读入 buffer pool，InnoDB 必须把所有相关
ibuf entry应用上去，这会拖慢首次读取响应 - 占用 buffer pool 内存：由
innodb_change_buffer_max_size控制，默认 25%，调太高会挤占真实数据页缓存空间 - 只适用于非唯一二级索引：主键、唯一索引、全文索引、空间索引、含降序字段的索引均不支持
- 如果业务大量执行
SELECT ... FOR UPDATE或频繁按二级索引查最新数据，反而可能因 merge 延迟导致锁等待或一致性视图复杂化
真正影响性能的，从来不是“有没有 change buffer”，而是你写的 SQL 是否命中它的生效边界，以及 buffer pool 是否足够大到让多数热索引页常驻内存 —— 后者一到位，change buffer 的出场机会反而大幅减少。
