先给结论：高并发写场景下，「写吞吐上不去」和「P99 抖」往往不是同一件事，而是同一件事——根因是 redo log 的 fsync 成本没被组提交吃掉。把 innodb_flush_log_at_trx_commit 从 1 调到 2、配合 sync_binlog 一起调，我们一个订单流水服务的峰值写入吞吐从 2100 rows/s 提到 4300 rows/s（约 2 倍），P99 从 41ms 降到 9ms。代价是宕机可能丢约 1 秒内未落盘的事务——这笔账必须先算清，再决定用哪个参数。
写之前先说一句：站内连接池那篇（id=18）讲过一个通用原则——「池子只是阀门，真正杠杆是谁在持有、持有多久」。组提交是同一思路在「提交」这一层的落地：你看到的「慢」，不是单次 INSERT 慢，而是提交这一步被 fsync 卡住、且没被合并。幂等写入那篇（id=601）讲的 ODKU 锁等待放大 P99，是「等锁」的尾延迟；组提交讲的是「等盘」的尾延迟。两者都只在 P99 那 1% 的尾部显形，平均值骗你——这是共性，下面分开讲。
一、现象与背景：P50 很稳、P99 在抖，吞吐卡在「天花板」
场景：一张订单流水表 t_order_flow（MySQL 8.0.32 / InnoDB / RR 隔离级别），1.0 亿行，PK 自增 id，无二级索引冲突。应用侧单分片峰值 2000 QPS 的单行 INSERT，事务里就一条 INSERT + commit。
innodb_flush_log_at_trx_commit=1（默认）、sync_binlog=1（默认）、binlog_format=ROW；- 磁盘是云盘（NVMe 类），单机 fsync 实测 0.6~1.2ms；
- 压测结果：P50 3.4ms，P99 41ms，峰值吞吐卡在 ~2100 rows/s 上不去，再加并发吞吐不涨、P99 反而涨；
SHOW STATUS LIKE 'Innodb_log_waits'在压测 5 分钟里从 12 涨到 238——这是第一个红旗（含义见下）。
诡异点：CPU 才 35%、buffer pool 命中率 99.7%、innodb_row_lock_waits 干净、慢日志没有 >100ms 的条目。所有「常规」指标都健康，唯独吞吐有天花板、P99 有尖刺。这类「平均值骗你」的写场景，十有八九要往「提交/刷盘」上找。
二、原理与根因：fsync 是硬成本，组提交是唯一解
把一个事务的「写」拆成四步，看每步在等什么：
- 写 undo + 改聚簇索引页 → 数据页变 dirty，留在 buffer pool（内存，快）；
- 写 redo log：把变更以顺序写追加进 log buffer，再落到 OS page cache（顺序写，快）；
- fsync redo log：把 page cache 里的 redo 真正刷到磁盘（这是硬成本，一次 0.6~1.2ms）；
- 返回 commit 成功。
关键在第 3 步：innodb_flush_log_at_trx_commit=1 的语义是每个事务提交前，都必须等它自己那部分 redo fsync 完成。2000 QPS 就意味着 2000 次/秒的独立 fsync，而磁盘的 fsync 在 OS 层无法真正并行（同一文件的 fsync 是串行的）——这就是吞吐天花板：max_rows/s ≈ 1000ms / 单次fsync，0.6ms 理论上限约 1600、1.2ms 约 800，加上 binlog 还要再 fsync 一次，实测 2100 已经接近这个量级，再加并发只会排队、P99 暴涨。
组提交（group commit）就是来合并第 3 步的。机制（MySQL 5.7+ 的 2 阶段 + log buffer 排队）：
- 多个线程几乎同时 commit，被串成一个「组」；
- leader 是组里第一个进入 sync 阶段的线程，负责把整组的 redo 一次性 sync 到 OS、再一次性 fsync；
- 组里其他成员（follower）不各自 fsync，而是等 leader 的这次 fsync 完成。
于是 N 个事务的 N 次 fsync 被合并成 1 次 fsync，成本从 N × fsync 降到 ≈ fsync。组越大、合并越省——前提是这些事务的 commit 时间足够接近，能落进同一个窗口。窗口太小（commit 间隔 > 一次 fsync 耗时），组就退化成一堆「单成员组」，等于没合并，Innodb_log_waits 就会涨——这就是我们上面看到 12→238 的含义：log 组提交窗口在「打滑」，每个事务几乎都在等自己的 fsync。
为什么 P99 也受益：没合并时，排在队尾的事务要等前面所有 fsync 串行完成，尾延迟 = 队深 × fsync；合并后，整组共享一次 fsync，队尾事务不再被「前面的人」拖着，P99 自然塌下来。吞吐和 P99 同涨，是组提交生效的典型指纹——如果你只看到吞吐涨、P99 没动，多半是某个环节没合并干净（见第四节）。
三、具体做法：参数要「成对」改，别只动一个
1. 先确认瓶颈在「提交/刷盘」，而不是「等锁」
-- 红旗：log 组提交窗口打滑，数值随压测持续增长说明 fsync 没被合并
SHOW STATUS LIKE 'Innodb_log_waits';
SHOW STATUS LIKE 'Innodb_log_writes'; -- fsync 次数，和 waits 对比看趋势
SHOW STATUS LIKE 'Com_commit'; -- 提交总数，算 fsync/commit 比值
SHOW STATUS LIKE 'Innodb_buffer_pool_wait_free';
SHOW STATUS LIKE 'Innodb_row_lock_waits'; -- 若这个也涨，先治锁（见 id=601）
判断口径：Innodb_log_writes / Com_commit 远小于 1，说明组提交在工作（一次 fsync 服务多个 commit）；接近 1 甚至 >1，说明几乎每个 commit 都单独 fsync，没合并。
2. 改参数（成对，别只改一个）
-- ① 让 redo 的 fsync 频率降下来：1→2
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
-- ② binlog 的 fsync 也要一起降，否则 binlog 成为新瓶颈（见第四节坑 1）
SET GLOBAL sync_binlog = 100;
innodb_flush_log_at_trx_commit=2：commit 时只把 redo 写到 OS page cache（每次 commit 都 sync 到 OS，但不 fsync），靠 OS 周期性（约每秒）落盘。宕机最多丢「OS 缓存里还没落盘」的那批；sync_binlog=100：每 100 个事务才强制 fsync 一次 binlog，让 binlog 的 fsync 也走「摊薄」；- 两个必须一起动：只改 redo、不改 binlog，binlog 的 fsync 会成为新的串行点，吞吐涨一半就卡住。
3. 给业务的「选择器」：按可容忍丢失量定档
| 档位 | 参数 | 宕机最多丢 | 适用 |
|---|---|---|---|
| 最稳 | trx_commit=1 + sync_binlog=1 | 0（双 1） | 资金、订单主表 |
| 折中 | trx_commit=1 + sync_binlog=100 | binlog 内 ≤100 事务 | 可重算的流水 |
| 吞吐优先 | trx_commit=2 + sync_binlog=100 | OS 缓存内（约 1 秒内） | 埋点、日志、可重放事件 |
我们这条订单流水是「可重算 + 上游有幂等表兜底」，选了第三档，所以敢把 P99 和吞吐一起换。
4. 压测与验证（可复现）
# 单连接写吞吐基线（改参数前后各跑一次，记录 rows/s 和 P99）
sysbench oltp_write_only --mysql-host=127.0.0.1 --mysql-port=3306 \
--mysql-db=bench --mysql-user=bench --mysql-password=[已脱敏] \
--tables=1 --table-size=1000000 --db-ps-mode=disable \
--threads=16 --time=120 --report-interval=10 run
验证指纹（改参数后应同时满足）：
Innodb_log_writes / Com_commit比值显著下降（合并生效）；- 吞吐翻倍、P99 下降（组提交指纹）；
Innodb_log_waits增长速率明显放缓。
四、踩过的坑与反直觉之处
坑 1：只改 trx_commit、不改 sync_binlog，吞吐只涨一半就卡住。
我们第一版只把 redo 调到 2，吞吐从 2100 涨到 3000 就上不去了，P99 还在 25ms。加 SHOW STATUS LIKE 'Com_commit' 和 binlog 的 fsync 计数一对，发现 binlog 的 fsync 成了新的串行点——ROW 格式下 binlog 体积比 redo 还大，fsync 更贵。教训：redo 和 binlog 是两条独立的「fsync 流水线」，谁没合并，谁就是瓶颈。
坑 2：Innodb_log_waits 在涨，但你以为是「日志不够大」去调 innodb_log_buffer_size——调了没用。
Innodb_log_waits 涨的真正含义是「组提交窗口打滑」：commit 间隔 > 一次 fsync，导致每次几乎单独 fsync。它和 log buffer 大小几乎无关。正确动作是提高 commit 的并发聚集度（让事务在时间上更密集地 commit）或直接放宽 trx_commit，而不是去加 buffer。
坑 3：fsync「次数」不是越少越好，是「单次服务的事务数」越高越好。
反直觉点：组提交不是「少刷盘」，而是「一次刷盘服务更多事务」。所以判断好坏的指标不是 Innodb_log_writes 绝对值，而是 Innodb_log_writes / Com_commit 这个比值。比值越低越健康。很多团队盯着绝对值调，方向就错了。
坑 4：压测 P99 达标 ≠ 生产安全，「崩溃恢复」才是 trx_commit=2 的真正成本。
trx_commit=2 的丢数据风险不在「平时」，而在「宕机那一刻」。我们做过一次 kill -9 演练：改 2 之后，宕机重启最多丢了约 0.8 秒内的写入（OS 还没来得及落盘）。这笔账必须写进业务的 SLO——如果你的链路没有「上游幂等 + 可重放」兜底，trx_commit=2 就是裸奔。
坑 5：binlog 文件切换（rotate）的瞬间，P99 会有一个尖刺。 这是和组提交无关、但会污染你 P99 曲线的另一个「等盘」源。binlog 切文件时新文件要 fsync 一次，叠加到那一刻的提交上。如果你的 P99 尖刺是「周期性、间隔约等于 binlog 切文件频率」，别急着怪组提交，先查 binlog 切换。
五、结论与可复用清单
结论：高并发写的「吞吐天花板 + P99 尖刺」，根因常常是 redo/binlog 的 fsync 没被组提交合并。解法是把 innodb_flush_log_at_trx_commit 和 sync_binlog 成对放宽，让「一次 fsync 服务更多事务」。代价是宕机丢失窗口变大，必须用业务的「可容忍丢失量 + 上游兜底能力」来定档。
可复用清单（按这个顺序排查）：
- 先定性：
Innodb_row_lock_waits涨？→ 去治锁（参考 id=601 的 ODKU/锁等待）。不涨、但Innodb_log_waits涨？→ 是「等盘」，进第 2 步。 - 算比值：
Innodb_log_writes / Com_commit。接近 1 → 组提交没合并，是 fsync 瓶颈；远小于 1 → 组提交在工作，瓶颈在别处（IO 带宽、CPU、锁）。 - 成对改参：
trx_commit和sync_binlog一起动，别只改一个（坑 1）。 - 定档：用「可容忍丢失量」选
1/1、1/100、2/100三档之一，写进 SLO（坑 4）。 - 压测看指纹：吞吐涨 且 P99 降 且
Innodb_log_waits增速放缓，三者同时满足才算组提交生效（坑 3 的比值要一起看）。 - 排除干扰：P99 尖刺是周期性的？先查 binlog 切换、磁盘队列深度，别全怪组提交（坑 5）。
- 兜底前置：选
trx_commit=2之前，确认链路有「上游幂等 + 可重放」，否则裸奔。
一句话：组提交不是「加个参数」，是把「N 次 fsync」合并成「1 次 fsync」的机制；你要做的不是「少刷盘」，而是「让每次刷盘服务更多事务」，并且为「少刷的那次」买好兜底保险。
引用：连接池「池子只是阀门、真正杠杆是谁在持有、持有多久」（id=18，林砚舟）；幂等写入「ODKU 把锁等待放大到 P99 那 1% 尾部」（id=601，陈寒山-172）。