MySQL 8.4 Change Buffer 实战：批量写入为什么没有把二级索引拖垮

有些批量写入事故很容易误判。业务说“只是导入一批订单扩展字段”，监控上却看到磁盘 I/O 拉高、普通查询 P99 抖动、二级索引页读写明显增加。这个时候如果还按 MySQL 8.0 的老经验说“Change Buffer 会帮你扛住”，在 MySQL 8.4 上可能会踩坑：innodb_change_buffering 的默认值已经是 none。

这篇只讲 MySQL 8.4 / InnoDB。官方文档说明 Change Buffer 用来缓存不在 Buffer Pool 中的二级索引页变更，后续再 merge；它能减少随机 I/O，但也会占用 Buffer Pool，并且 merge 可能在事务提交后继续影响磁盘。工程上要把它当成 I/O 权衡，而不是加速开关。

一、业务场景：批量更新把二级索引打散

假设订单表有几个常见二级索引，白天在线写入不多，夜间要批量补齐风控字段：

CREATE TABLE order_risk (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  tenant_id BIGINT NOT NULL,
  order_no VARCHAR(64) NOT NULL,
  risk_level TINYINT NOT NULL,
  updated_at DATETIME NOT NULL,
  PRIMARY KEY (id),
  KEY idx_tenant_risk (tenant_id, risk_level),
  KEY idx_updated_at (updated_at),
  UNIQUE KEY uk_order_no (order_no)
) ENGINE=InnoDB;

UPDATE order_risk
SET risk_level = ?, updated_at = NOW()
WHERE tenant_id = ?
  AND order_no = ?;

如果更新命中大量随机二级索引页，而这些页又不在 Buffer Pool 里，InnoDB 可能需要频繁读页再改页。Change Buffer 的价值就在这里：先把部分二级索引变更缓存起来，等相关页被读入时再合并。

二、先确认当前 MySQL 8.4 的默认行为

不要靠记忆。上线前先查变量：

SHOW VARIABLES LIKE 'innodb_change_buffering';
SHOW VARIABLES LIKE 'innodb_change_buffer_max_size';

在 MySQL 8.4 文档里，innodb_change_buffering 默认是 none，而不是早期版本常见的 all。这意味着如果你从旧版本迁移过来，批量写入的 I/O 曲线可能会变得不一样。

三、什么时候它会帮忙，什么时候会添乱

我会把场景分成两类。

• 可能有价值：写入量大、二级索引多、索引页随机分布、工作集明显大于 Buffer Pool，瓶颈主要是磁盘随机 I/O。
• 收益有限甚至负面：热点数据基本都在 Buffer Pool、二级索引很少、主要瓶颈是唯一键冲突或 redo 刷盘、业务更关注在线查询 P99。

Change Buffer 占用 Buffer Pool 的一部分。你的工作集如果刚好接近内存容量，打开它可能挤掉原本要缓存的数据页，读查询反而抖。

四、诊断：先看是不是二级索引随机 I/O

排障时我不会直接改参数，而是先收集这几组信息：

SHOW ENGINE INNODB STATUS\G

SELECT name, count
FROM information_schema.innodb_metrics
WHERE name LIKE 'ibuf%'
ORDER BY name;

不同实例是否开启相关 metrics、名称是否完整，要以实际环境为准。这里的重点不是背字段，而是判断：是否存在 change buffer 使用、merge 是否跟不上、磁盘 I/O 是否随 merge 反弹。

五、压测脚本要覆盖读写混合

只压 INSERT 或 UPDATE 吞吐是不够的。真实线上问题通常是写入任务让读查询 P99 抖动，所以压测至少要并行两类 SQL：

-- 写入侧：模拟批量补偿
UPDATE order_risk
SET risk_level = risk_level + 1, updated_at = NOW()
WHERE id BETWEEN ? AND ?;

-- 读取侧：模拟在线查询
SELECT id, order_no, risk_level
FROM order_risk
WHERE tenant_id = ? AND risk_level = ?
ORDER BY updated_at DESC
LIMIT 50;

然后分别测试 none、inserts、changes。不要一上来用 all，也不要只看平均值。写入吞吐、读 P99、磁盘 util、Buffer Pool 命中率都要一起看。

六、变更建议：小步试，不要全库拍脑袋

-- 示例：只在灰度实例评估，不要直接全量改生产
SET GLOBAL innodb_change_buffering = 'changes';

-- 如需持久化，再用变更单执行
SET PERSIST innodb_change_buffering = 'changes';

修改后，新操作会按新策略处理，已有 buffered entries 的 merge 不会因为你改回去就瞬间消失。所以回滚方案里要写清楚：什么时候回滚参数，什么时候停止批量任务，什么时候观察 merge 尾部影响。

七、上线检查单

• 确认目标实例是 MySQL 8.4，实际变量不是旧版本继承值。
• 确认表上二级索引数量、写入分布和 Buffer Pool 命中情况。
• 灰度压测覆盖读写混合，不只看批量写入耗时。
• 观察 SHOW ENGINE INNODB STATUS 与 innodb_metrics 的变化。
• 准备停止批量任务、回滚参数和等待 merge 收尾的方案。

八、我的结论

Change Buffer 是一个很典型的 InnoDB 工程权衡：它不是越开越快，也不是默认 none 就永远不用管。MySQL 8.4 把默认值放到 none，反而要求我们更明确地判断负载类型。写多、二级索引多、随机 I/O 重，可以评估；读延迟敏感、数据热、内存紧，先别急着开。参数调整必须跟压测、监控和回滚一起上线。