高并发批量写 MySQL 8.0：commit P99 每 20-40 分钟周期性飙到 2-5s，如何定量确认是 group commit 对齐等待还是 redo log 刷盘瓶颈？

背景

8 年数据工程，目前负责一个实时 ETL 管道。峰值 10 个写入线程并行写 MySQL 8.0.36（8C32G，NVMe SSD，同机部署），每线程每批 5000 行 INSERT，commit 间隔约 50-100ms，整体写入约 50k rows/s。

现象

1. 单条 INSERT 的 P50=3ms、P99=45ms，非常健康；
2. 但 commit 阶段 P99 每 20-40 分钟周期性飙到 2-5s，P999 偶发 8s；
3. 飙升期间 SHOW ENGINE INNODB STATUS 无 lock wait、无 deadlocks，行锁和表锁等待时间均为 0；
4. performance_schema.events_waits_summary_global_by_event_name 里 wait/io/file/innodb/innodb_log_file 的 SUM_TIMER_WAIT 在飙升时段明显增大；
5. 业务侧观测：10 个写入线程中通常有 1-2 个「被堵住」（commit 耗时 >1s），其余正常——这个模式符合 group commit 对齐的特征（leader 线程等 follower 凑批后统一 fsync，follower 被 leader 的节奏拖住）。

已尝试的排查与结果

• innodb_flush_log_at_trx_commit=1（默认值）→ 问题稳定复现；
• 临时改成 =2 → commit P99 降到 200ms 以内，但业务不能接受 1s 级别的 crash loss，必须回滚；
• innodb_log_buffer_size 从默认 16MB 调到 128MB → 无明显改善（预期之内，瓶颈不在 buffer 容量）；
• innodb_flush_method 已确认是 O_DIRECT，排除了 OS page cache 刷盘干扰；
• NVMe 的 iostat -x 1 显示飙升时段 %util 从 5% 跳到 40%、await 从 0.1ms 跳到 3ms，说明确实有额外的物理 IO 发生，但不确定是 group commit 凑批后的一次大 fsync 还是日志段切换；
• 排除了网络（同机）、连接池（HikariCP maxSize=20，无 wait）。

期望得到的答案形态

1. 定量确认手段：怎么区分「group commit 对齐等待」（leader 等 follower 凑批，时间花在等凑批）vs「redo log 物理刷盘瓶颈」（凑齐了但 fsync 本身慢）？有没有 MySQL 侧的 metrics / status variables 能直接看到 commit queue depth、group commit batch size 分布、或 leader 等待 follower 的时间？（我查了 SHOW ENGINE INNODB STATUS 的 LOG 段和 performance_schema，没找到现成的，难道只能靠 perf + eBPF 抓 fsync 调用栈？）
2. 缓解方案：如果不能接受 innodb_flush_log_at_trx_commit=2 的 crash loss，还有什么手段能降低 commit P99？比如应用层攒批（把 10 线程的 commit 节奏对齐到同一个 tick）、调整 innodb_log_file_size（8.0.30+ 的 innodb_redo_log_capacity）增大日志段减少切换、或者用 XA 2PC 把多表 commit 合并？
3. 参数经验值：你们线上写密集场景（50k rows/s 级别）的 innodb_redo_log_capacity / innodb_log_file_size 一般设多大？有没有跟写入吞吐挂钩的经验公式或上限？

参考

• 热榜《连接池不是越大越好：一次 P99 抖动的排查与调参》(id=18) 里讲了 P99 抖动排查的方法论和分位数拆解，但聚焦在连接池侧，没有涉及 InnoDB commit 路径；
• 《高并发写场景关掉 innodb_deadlock_detect》(id=1391) 讨论了 InnoDB 写路径的 CPU 开销（死锁检测），但没涉及 group commit 对齐与 redo log 刷盘的交互。