InnoDB Change Buffer 在主库高并发 OLTP 下的反噬：一次把默认优化关掉反而变快的复盘

结论先行：innodb_change_buffering=all 是 MySQL 默认值，但它的适用场景是"读多写少 + 二级索引热页稀疏"。在主库高并发 OLTP 里，Change Buffer 的 merge 风暴反而是 P99 尖刺的隐形来源。我们把默认值改成 none 之后，P99 从 52ms 降到 8.4ms，写入 QPS 反升 6.9%。

一、现象：P50 稳定 3ms，P99 却每 20~30 秒飙一次 40ms+

去年 Q4 给一家做 B2B 撮合的电商客户做订单主库的性能巡检。环境是 MySQL 8.0.32（主 16C64G、NVMe SSD Intel P4510 3.84T、innodb_buffer_pool_size=48G），业务侧是订单创建 + 状态流转的写密集链路，稳定 QPS ~3500。

症状很典型也很反直觉：

• P50 稳定在 3.2ms，业务侧体感"还行"；
• P99 每隔 20~30 秒出现一次 40~80ms 的尖刺，持续 200~500ms；
• top 里 CPU 只到 60%、iowait 12%，Buffer Pool 命中率 99.7%；
• 慢查询日志几乎干净，没有单条 SQL 超过 50ms；
• 连接池没打满，锁等待队列 SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 段也看不到长事务。

按常规套路——查慢日志、看连接池、查锁、看 GC——全部排空。业务方开始怀疑是不是内核的 cgroup 限流，我们才把 perf top 拉出来看。

二、根因：Change Buffer 的 merge 风暴

InnoDB 的 Change Buffer（IBUF）机制：写入二级索引时，如果目标索引页不在 buffer pool，InnoDB 不会立刻去磁盘把页读进来再改，而是先把这个变更以"cell"的形式挂到 IBUF（本身也是一棵 B+ 树），等这个索引页因为被读而进 buffer pool 时，再把 cell merge 进去。

设计初衷很清晰：读多写少、二级索引热页稀疏的场景下（日志、埋点、审计），IBUF 能把"写时随机读"省掉，把成本摊到"读时顺手 merge"。

但主库 OLTP 场景下，这三件事同时发生：

1. 业务侧写完紧跟读——订单创建后立刻 SELECT 状态、列表、详情，索引页几秒内就会被读进 buffer pool；
2. 每次 merge 都要做一次随机读 + 一次随机写，且同一索引页的 merge 是串行的（要拿页锁）；
3. IBUF 本身是 B+ 树，ibuf_merge_or_delete_for_page 在页多时是 CPU 热点。

SHOW ENGINE INNODB STATUS\G 的 Change buffer 段给出了实锤：

• Number of merges 增长到 120 万/小时；
• Number of cells merged / Number of inserts 比例 0.34——意味着 1/3 的写入走了 IBUF 路径（健康值应该 < 0.05）；
• Pending reads / Pending writes 峰值 3000+；
• Change buffer (_100.0%_full) 一度到 97%。

perf top 里 ibuf_merge_or_delete_for_page + buf_flush_page_clean 两个函数加起来占 18% CPU——这就是"CPU 不忙但 P99 抖"的经典信号：合并工作被摊到后台，但一旦同一事务持有的行锁碰上 merge 页锁，后续 INSERT 就会排队。

三、具体做法：先量化，再灰度，最后落盘

步骤 1：先确认 IBUF 到底在不在吃资源

SHOW ENGINE INNODB STATUS\G

重点看 Change buffer 段：Number of merges 的增速、Number of cells merged / Number of inserts 的比例、Pending reads/writes 的峰值。同时 perf top -p <mysqld_pid> 看 ibuf_merge_or_delete_for_page 占比。

步骤 2：压测 A/B

• 基线：默认 innodb_change_buffering=all，innodb_change_buffer_max_pct=25；
• 实验 A：SET GLOBAL innodb_change_buffering = 'none';（IBUF 完全关闭，二级索引写入走同步页写）；
• 实验 B：innodb_change_buffering='none' + innodb_change_buffer_max_pct=5（兜底，防极端场景）。

压测脚本用 k6，固定 3500 QPS 持续 10 分钟，取 P50/P99/QPS 三项。

结果（单机，NVMe SSD）

| 指标 | 基线 (all) | 实验 A (none) | 实验 B (none+5%) | |---|---|---|---| | P50 | 3.2ms | 2.7ms | 2.8ms | | P99 | 52ms | 8.4ms | 9.1ms | | 写入 QPS | 3480 | 3720 | 3690 | | 单次 INSERT 均值 | 2.9ms | 2.6ms | 2.7ms | | ibuf_* CPU 占比 | 18% | 0% | 0% |

参数落盘

[mysqld]
# 主库 OLTP：关闭 IBUF，把写入路径从"异步 merge"改成"同步页写"
innodb_change_buffering = none
# 保留兜底容量，防极端读少写多场景
innodb_change_buffer_max_pct = 5

注意：innodb_change_buffering 是动态参数，可以 SET GLOBAL 在线改，但必须落盘否则重启回滚。

四、踩过的坑与反直觉之处

1. innodb_change_buffering=none 不是"省 I/O"，而是"把异步 merge 变成同步索引页写"。如果索引页真的不在 buffer pool，写入路径会多一次随机读。所以在读多写少的场景（日志、埋点、审计）关掉反而更慢——我们内部有 2 个埋点库就是反例，关 IBUF 后 P99 反而从 12ms 涨到 21ms。
2. 看 SHOW ENGINE INNODB STATUS 的 Change buffer 段不能只看 Number of merges 总量，要看 Number of cells merged / Number of inserts 的比例。我们场景这个比例到了 0.34，而健康值应该 < 0.05。比例 > 0.2 基本可以判定"IBUF 在反噬"。
3. innodb_change_buffer_max_pct 默认 25，但很多人不知道这个参数在 none 模式下也生效——它决定了 IBUF 在 buffer pool 里能占多大。调到 5 会挤占 buffer pool，得不偿失；调到 50 在 none 模式下等于白占内存。
4. 压测时 CPU 只用了 60%，但 perf top 里 buf_flush_page_clean 和 ibuf_merge_or_delete_for_page 加起来占 18%——这就是"CPU 不忙但 P99 抖"的经典信号。永远不要只看 CPU 总量，要看热点函数。
5. 关 IBUF 之前先确认 buffer pool 命中率 > 99%。如果命中率只有 95%，说明 buffer pool 本身就不够，关 IBUF 会放大随机读，雪上加霜。

五、结论与可复用清单

什么时候别关 Change Buffer：

• 读多写少（日志、埋点、审计、监控）
• 二级索引基数大、单索引页命中率低
• 磁盘是 HDD、随机读贵
• Buffer pool 命中率 < 99%

什么时候该关：

• 主库 OLTP、写密集
• 二级索引热页多（业务侧写完紧跟读）
• 磁盘是 NVMe SSD、随机读便宜
• Number of cells merged / Number of inserts > 0.2

可复用检查清单（按顺序做）：

1. SHOW ENGINE INNODB STATUS\G 看 Change buffer 段，算 cells merged / inserts 比例；
2. perf top -p <mysqld_pid> 看 ibuf_merge_or_delete_for_page 占比，> 5% 就要警惕；
3. 压测前后对比 P50/P99/QPS 三项，P99 的改善幅度通常远大于 P50；
4. 灰度一台从库（读流量）做 A/B，别直接动主库；
5. 关之前先确认 buffer pool 命中率 > 99%；
6. 落盘 innodb_change_buffering=none + innodb_change_buffer_max_pct=5，重启验证；
7. 观察 1 周，重点看 P99 尖刺频率与 ibuf_* 函数是否归零。

一句话总结：Change Buffer 是"写随机索引页"的优化，不是"写密集 OLTP"的优化。默认值不等于最优值，先量化再动参数。