binlog_group_commit_sync_delay 默认 0 才是最优：两个"合并事务"参数在 NVMe 上把 P99 拖高 38% 的复盘

结论先行：binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 默认值 0 在 NVMe 上就是最优解。这两个参数名字像"合并事务提升吞吐"，但机制是"主动引入延迟去凑 batch"，在 NVMe 单事务 commit 只要 0.2-0.4ms 的场景下，任何非零值都是纯税——我们实测把 delay 从 0 调到 10 后，P50 稳定不变，P99 从 4.2ms 涨到 5.8ms，QPS 从 28400 掉到 25100（-12%），完全是负收益。

一、现象与背景：吞吐没提升，P99 反而涨了

场景：一套账户交易流水系统，MySQL 8.0.32 / InnoDB / NVMe SSD（Intel P4510 3.84TB），主库 16C64G，innodb_buffer_pool_size=32GB。写入特征：

• 单条 INSERT + 2 个二级索引维护（idx_uid_time、idx_biz_no）
• 峰值 QPS 约 28000/s，P50=2.1ms、P99=4.2ms，非常稳定
• 持久化配置：innodb_flush_log_at_trx_commit=1、sync_binlog=1、innodb_flush_method=O_DIRECT

运维同学看到官方文档里 binlog_group_commit_sync_delay 的说明——"wait a specified number of microseconds before flushing the binary log, to allow other transactions to join the group commit"——以为"设大一点能合并更多事务、降低 fsync 次数"，在某次性能调优时把它从默认 0 改成了 10，同时 binlog_group_commit_sync_no_delay_count 也设成了 10。

改完 24 小时的对比数据（同一压测脚本，10 分钟稳态窗口）：

| 参数组合 | P50 | P99 | QPS | fsync/s | |---|---|---|---|---| | delay=0, count=0（默认） | 2.1ms | 4.2ms | 28400 | 27800 | | delay=10, count=10 | 2.2ms | 5.8ms | 25100 | 24600 | | delay=50, count=10 | 2.3ms | 12.4ms | 18300 | 17900 |

fsync 次数确实降了（合并生效了），但 P99 涨了 38%（10µs）到 195%（50µs），QPS 掉了 12% 到 35%。"合并"这个动作本身是成功的，但"为了合并而等待"的代价超过了合并省下的 fsync 成本——在 NVMe 上，一次 fsync 只要 0.2-0.4ms，而 delay=50 意味着每个事务多等 50µs，且这个等待是串行的（leader 在 flush 阶段结束后、sync 阶段开始前主动 sleep，后续事务必须等它走完才能开始自己的 group commit）。

二、原理：group commit 三阶段与"凑 batch"的代价

MySQL 的 binlog group commit 分三个阶段（binlog_group_commit_sync_delay 只影响第一阶段到第二阶段的衔接）：

1. flush stage：leader 把 group 内所有事务的 binlog event 顺序写入 OS page cache；
2. sync stage：leader 对 binlog 文件做一次 fsync（这就是 sync_binlog=1 的那个 fsync）；
3. commit stage：leader 把 group 内所有事务标记为 committed，释放锁，通知等待者。

binlog_group_commit_sync_delay 的作用点在 flush 结束、sync 开始之前：leader 在 flush 完之后、fsync 之前，主动 sleep delay 微秒，目的是"多等一会儿，让还没进入 commit 路径的事务也加入这个 group"，从而把多次 fsync 合并成一次。

binlog_group_commit_sync_no_delay_count 是"凑够 N 个就不等了"的早停条件：group 内事务数 ≥ N 时跳过 delay 直接进 sync。

关键机制：这个 sleep 发生在 leader 线程上，且处于"已 flush、未 fsync"的窗口里。在这个窗口内：

• 已 flush 但还没 fsync 的事务，其 binlog 仍躺在 page cache（未持久化）；
• 后续想 commit 的事务，必须等 leader 走完 sleep → fsync → commit 三阶段才能开始自己的 group commit（因为 binlog 文件的写入和 fsync 是串行的，同一时刻只有一个 leader）；
• 所以 delay 直接串行拉长了每个事务的 commit 路径，且对 P99 影响远大于 P50（P50 是"正常走"的事务，P99 是"恰好撞上 leader 正在 sleep"的那批事务）。

在 NVMe 上，一次 fsync 的边际成本只有 0.2-0.4ms，而 delay=50µs 的等待是确定的、不可并行的——你省下的 fsync 次数（假设从 28000/s 降到 18000/s，省了约 10000 次 fsync × 0.3ms ≈ 3s/s 的 IO 时间），换来的却是每个事务多等 50µs × 28000/s ≈ 1.4s/s 的串行等待，且 P99 被直接顶到 12.4ms。账算下来，合并省的钱 < 等待花的钱。

反过来，在 HDD 上（一次 fsync 5-15ms），合并的收益就大得多，delay 设 10-50µs 可能是正收益。这就是为什么这两个参数的"最优值"和存储介质强相关。

三、具体做法（可复现）

第一步：确认你的 fsync 边际成本

# NVMe 上典型值：单文件 fsync 0.2-0.4ms；HDD 典型 5-15ms
fio --name=fsync_test --filename=/tmp/fio_test --rw=write --bs=4k \
    --direct=1 --ioengine=sync --fsync=1 --numjobs=1 --runtime=30 \
    --group_reporting
# 看 fsync 的 avg 列，NVMe 通常 < 0.5ms，HDD 通常 5-15ms

第二步：用 performance_schema 量化 group commit 的实际合并率

SELECT VARIABLE_NAME, VARIABLE_VALUE
FROM performance_schema.global_status
WHERE VARIABLE_NAME IN (
  'Com_commit',
  'Binlog_commits',
  'Binlog_group_commits',
  'Innodb_log_waits'
);
-- Binlog_group_commits / Com_commit = 平均 batch size
-- 若 ratio > 1.5 说明合并有效；若 ≈ 1.0 说明基本没合并（NVMe 上正常）

第三步：压测对比（我们的脚本）

# 分别设 delay=0/10/50，各跑 10 分钟稳态窗口
sysbench oltp_write_only --mysql-table-size=50000000 \
  --mysql-db=bench --threads=64 --time=600 --report-interval=10 \
  --mysql-user=bench --mysql-password=*** --mysql-host=127.0.0.1 run
# 记录 P50/P99/QPS，同时 sar -d 1 看磁盘 await

第四步：参数设置建议

# NVMe / 云盘（fsync < 1ms）：保持默认，不要动
binlog_group_commit_sync_delay = 0
binlog_group_commit_sync_no_delay_count = 0

# HDD（fsync > 5ms）：可以试 delay=10~50, count=5~10
# 但务必先压测验证 P99 不恶化再上线

四、踩过的坑（反直觉处）

1. 官方文档的措辞有误导性：文档说"wait ... to allow other transactions to join the group commit"，读起来像"提升吞吐"，但实际上是"用延迟换合并"。MySQL 文档里其实有一句小字"this is useful when the storage is slow"，但很少有人注意到。在 fsync 便宜的场景下，这个交换是亏的。
2. sync_no_delay_count 不是"最少 batch size"：很多人以为设成 10 就是"凑够 10 个才 fsync"，实际语义是"如果 group 内已有 ≥10 个事务，就跳过 delay 直接 fsync"——它只是早停条件，不是最低门槛。如果 QPS 低、group 内只有 2 个事务，delay 照样会睡满。
3. 改参数不需要重启，但验证窗口要够长：SET GLOBAL binlog_group_commit_sync_delay = 10 即时生效，但 P99 的变化在 2 分钟内的监控里可能看不到（P99 是尾部指标，需要足够多的样本）。我们第一版只看了 2 分钟就回滚了，后来跑了 10 分钟才看到真实差异——对 P99 的评估，10 分钟稳态窗口是下限。
4. 和 sync_binlog 的交互：sync_binlog=10000 时，fsync 本身就不是瓶颈（每 10000 个事务才 fsync 一次），此时设 delay 几乎没有额外收益（因为 fsync 本来就很少），但 delay 的等待成本还在——在 sync_binlog > 1 的配置下，这两个参数几乎永远是负收益。

五、结论与可复用清单

该设非零值的信号：存储是 HDD / SATA SSD（fsync > 5ms）+ QPS > 10000 + 对 P99 不敏感（批处理、离线写入）。

不该设非零值的信号：NVMe / 云盘（fsync < 1ms）+ 在线 OLTP + P99 敏感。99% 的现代云数据库都落在这个区间，保持默认 0 就是最优解。

成本-收益清单（可直接照抄）：

• ✅ 收益（仅 HDD 场景）：fsync 次数减少 30-50%，HDD 随机写 IOPS 瓶颈缓解。
• ⚠️ 成本（所有场景）：每个事务在 commit 路径上多等 delay µs，P99 线性增长；在 NVMe 上这个成本 > 收益。
• 🚫 红线：sync_binlog > 1 时不要设 delay（fsync 本来就不是瓶颈，纯加等待）；不要凭"合并=更快"的直觉设值，先测 fsync 边际成本。
• 📏 判据：先跑 fio 测 fsync avg，再跑 sysbench 对比 P99/QPS，10 分钟稳态窗口才可信。

一句话：这两个参数是给"fsync 贵"的场景准备的，而现代 NVMe 上 fsync 不贵——默认 0 就是正确答案，动它之前先算一笔 fsync 边际成本的账。