MySQL COMMIT 语句本身不触发组提交，真正起作用的是 ordered_commit() 函数实现的 Flush、Sync、Commit 三阶段流水线调度，通过 Leader-Follower 机制将并发事务批量处理，仅由 Leader 执行 fsync 等耗时操作，从而大幅提升吞吐。
MySQL 的 COMMIT 操作本身不直接触发组提交；真正起作用的是 ordered_commit() 函数在 Binlog 层对事务提交流程的三阶段调度——Flush、Sync、Commit，且必须满足特定参数组合才实际生效。
为什么 COMMIT 语句看起来“串行”但实际能组提交？
执行 COMMIT 时，InnoDB 先完成 prepare（写 redo log），再交由 MySQL Server 层调用 MYSQL_BIN_LOG::ordered_commit()。这个函数不等每个事务单独走完 fsync，而是把同时到达的事务按阶段排队：第一个进队的变成 leader，其余为 follower，leader 统一执行耗时操作，follower 等通知即可返回。
- 事务不会卡在
COMMIT语法层面，而是卡在ordered_commit()的某个阶段队列里（比如 Sync 阶段等待leader调用fsync(binlog)） - 如果所有事务都很快完成 prepare 并几乎同时进入 Flush 阶段，就容易凑成大组；反之，若事务执行时间差异大，或锁争用严重，
follower可能早早就超时退出队列，导致组变小甚至退化为单事务提交 -
COMMIT返回成功 ≠ 数据已落盘，只是表示该事务已被leader收编并承诺会随组一起持久化
sync_binlog 和 innodb_flush_log_at_trx_commit 怎么掐住组提交的命门？
这两个参数决定事务是否真能“排队等打包”。只要其中任意一个强制每事务刷盘，leader 就没机会攒人。
-
sync_binlog = 1+innodb_flush_log_at_trx_commit = 1→ 每个事务都要求fsyncredo 和 binlog，ordered_commit()的 Sync 阶段形同虚设，组提交退化为串行，TPS 可能腰斩 - 推荐生产搭配：
sync_binlog = 1（保主备一致） +innodb_flush_log_at_trx_commit = 2（redo 只写 OS cache），这样 Binlog 层仍有打包空间，InnoDB 层也不拖后腿 -
innodb_flush_log_at_trx_commit = 0虽吞吐高，但崩溃可能丢 1 秒事务，仅适合从库或日志可丢场景；sync_binlog = 0完全不可控，主库禁用
怎么确认组提交真在干活，而不是配置写了就完事？
别信配置文件，查运行时状态变量才是唯一验证方式。
-
SHOW GLOBAL STATUS LIKE 'Binlog_group_commit_trigger_count';—— 这个值持续上涨，说明有事务被成功打包；长期为 0 表示组提交压根没启动 -
Binlog_group_commit_trigger_lock_wait持续涨 → 事务卡在 MDL 锁或行锁上，根本没走到提交队列，leader等不到人 -
Binlog_group_commit_trigger_timeout每秒涨几十次 →binlog_group_commit_sync_delay设太大（如 500000 微秒），小事务被迫等满才发车，延迟爆炸 - 用
pt-query-digest看慢日志时，重点筛Query_time短但Lock_time长的语句——它们就是拖垮整组的“钉子户”
binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 怎么调？
这两个参数控制“发车策略”，是 or 关系：满足任一即触发刷盘，但调得过激会牺牲延迟。
-
binlog_group_commit_sync_delay = 10000（10ms）+binlog_group_commit_sync_no_delay_count = 10是较平衡起点；高吞吐低延迟场景可压到 1000～5000 微秒 - 设成 500000（500ms）是典型错误——P99 延迟直接抬升半秒，用户感知明显卡顿
-
binlog_group_commit_sync_delay = 0时，binlog_group_commit_sync_no_delay_count失效，相当于“人不满也发车”，组变小，吞吐下降 - 调整后必须观察
Binlog_group_commit_trigger_count是否上升，以及Com_commit与Handler_commit的比值是否趋近于组大小（如比值 ≈ 8，说明平均每组 8 个事务）
组提交不是开个开关就自动生效的魔法，它高度依赖事务到达节奏、锁竞争状况和两个关键刷盘参数的配合。最容易被忽略的是：即使参数配对正确，若业务 SQL 存在长锁等待或大事务阻塞，follower 根本等不到进队就超时退出，整个机制就空转。
