sync_binlog与innodb_flush_log_at_trx_commit组合决定组提交是否生效：二者均为1时退化为串行提交，推荐sync_binlog=1+innodb_flush_log_at_trx_commit=2以兼顾主备一致与性能；需通过binlog_group_commit_trigger_count等状态变量验证实际效果，并避免锁竞争等内部瓶颈。
sync_binlog 和 innodb_flush_log_at_trx_commit 的组合决定组提交是否生效
组提交不是“开个开关就自动生效”，它被这两个参数的组合直接掐住脖子。只要 sync_binlog=1 且 innodb_flush_log_at_trx_commit=1，每个事务都强制刷盘，leader 线程根本没机会攒队列——组提交退化成串行提交，TPS 可能掉 50% 以上。
生产环境推荐搭配：sync_binlog=1 + innodb_flush_log_at_trx_commit=2。这样 binlog 强制刷盘（保证主备一致），InnoDB redo 日志只写 OS 缓存（不 fsync），既保住数据安全底线，又让组提交能真正聚合事务。
-
innodb_flush_log_at_trx_commit=0：日志每秒刷一次，吞吐最高但崩溃可能丢一秒数据，仅适合从库或日志可丢场景 -
sync_binlog=0：binlog 完全依赖 OS 刷盘，风险极高，不建议在主库启用 - 绝对避免
sync_binlog=1+innodb_flush_log_at_trx_commit=1组合跑小事务高频写入
用状态变量验证组提交是否真在工作
别信配置文件写了就等于生效。必须查运行时状态：
SHOW GLOBAL STATUS LIKE 'Binlog_group_commit_trigger_count'; —— 这个值持续增长，说明有事务被成功打包；如果长期为 0，组提交压根没启动。
再看另外两个关键指标：
-
Binlog_group_commit_trigger_lock_wait持续上涨 → 事务卡在 MDL 锁或行锁上，还没走到提交阶段，leader 就等不到 follower -
Binlog_group_commit_trigger_timeout每秒涨几十次 →binlog_group_commit_sync_delay设得太大，小事务被迫排队等超时才提交，延迟飙升
用 pt-query-digest 分析慢日志时，重点筛 Query_time 短但 Lock_time 长的语句——它们就是拖垮整个组的“钉子户”。
调整组提交触发阈值：别让 delay 成为瓶颈
组提交靠两个参数控制“何时打包”：binlog_group_commit_sync_delay（微秒级等待）和 binlog_group_commit_sync_no_delay_count（凑够 N 个就发）。
典型错误是把 binlog_group_commit_sync_delay 设成 500000（500ms），结果所有小事务平均卡半秒才提交，响应时间直接崩。实际应设为 10000～100000（10ms～100ms），视业务 P99 延迟容忍度而定。
- 高吞吐低延迟场景：优先设小
binlog_group_commit_sync_delay（如 10000），靠binlog_group_commit_sync_no_delay_count（如 10）兜底 - 纯吞吐导向场景（如日志写入）：可适当提高 delay（如 50000），但务必配合压测观察
Binlog_group_commit_trigger_timeout - 这两个参数动态可调，无需重启 MySQL，但需确认版本支持（5.7+ 稳定，8.0 更精细）
组提交不是万能解药：锁竞争和 CPU 争用照样卡死
组提交只减少刷盘次数，不解决事务内部的锁冲突。小事务多意味着热点行更新密集，InnoDB 的行锁、buf_pool_mutex、自适应哈希索引（AHI）争用会立刻暴露出来。
这时候调 sync_binlog 没用。必须同步做：
- 检查事务内 DML 是否都命中索引，
EXPLAIN确认无全表扫描或隐式转换 - 拆分长事务，避免单个事务持有锁过久；批量操作改用分批提交（如每 200 条一个事务）
- 降低隔离级别到
READ COMMITTED（若业务允许），减少间隙锁范围 - 监控
Innodb_row_lock_waits和Innodb_mutex_spin_waits，定位具体锁点
真正压测时，你会发现 TPS 卡在某个值不再上升——那往往不是 IO 瓶颈，而是 InnoDB 内部结构争用开始限速了。
