MySQL组提交默认开启但实际生效取决于sync_binlog与innodb_flush_log_at_trx_commit组合；sync_binlog=1且innodb_flush_log_at_trx_commit=1时组提交失效，需合理配置参数并验证Binlog_group_commit_trigger_count等状态值。
MySQL组提交到底有没有生效
默认情况下，MySQL的组提交（Group Commit）在binlog层是开启的，但实际是否起效，取决于sync_binlog和innodb_flush_log_at_trx_commit的组合。常见误区是以为只要开了binlog就自动组提交——其实不是。当sync_binlog=1且innodb_flush_log_at_trx_commit=1时，每个事务都会强制刷盘，组提交被“阉割”成串行刷盘，吞吐直接掉一半以上。
验证是否真有组提交：查SHOW GLOBAL STATUS LIKE 'Binlog_group_commit_trigger_count'，非零说明有聚合；再看Binlog_group_commit_trigger_lock_wait和Binlog_group_commit_trigger_timeout是否频繁上升，那是组提交在等锁或超时，说明配置没调对。
-
sync_binlog=0：binlog只写入页缓存，依赖OS刷盘，风险高但吞吐最高，适合从库或日志可丢场景 -
sync_binlog=1+innodb_flush_log_at_trx_commit=2：InnoDB日志刷到OS缓存、binlog强制刷盘，兼顾安全与组提交效果，生产常用折中方案 - 绝对不要用
innodb_flush_log_at_trx_commit=1+sync_binlog=1跑高并发小事务，等于主动放弃组提交
如何确认小事务真的被“打包”了
组提交不是按事务数量打包，而是按时间窗口或队列长度触发。关键要看binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count这两个参数。前者是微秒级等待（比如设为100000即100ms），后者是凑够N个事务就不管延时不延迟立刻提交。
典型错误配置是把binlog_group_commit_sync_delay设得过大（如500000），结果小事务平均要卡半秒才提交，延迟飙升，反而拖垮响应时间。
- 压测时观察
Binlog_group_commit_trigger_timeout增长速度：如果每秒涨几十次，说明delay太长，该调小 - 如果
Binlog_group_commit_trigger_count几乎不涨，但Binlog_group_commit_trigger_lock_wait猛增，大概率是事务卡在MDL锁或行锁上，组提交根本没机会启动 - 用
pt-query-digest分析慢日志，重点筛出Query_time短但Lock_time长的语句，它们会拖住整个组
为什么用了组提交，TPS还是上不去
组提交只解决“刷盘次数”，不解决“锁竞争”和“CPU争用”。小事务多意味着热点行更新频繁，InnoDB的行锁、自适应哈希索引（AHI）、甚至buffer pool mutex都可能成为瓶颈。这时候光调binlog参数没用。
一个常被忽略的事实：binlog_group_commit_sync_delay设得再低，如果事务本身执行慢（比如update没走索引、触发大量二级索引维护），它还是会卡住后续事务进入组队列。
- 检查
Innodb_row_lock_waits和Innodb_row_lock_time_avg：平均锁等待超1ms就得查热点行 - 开
innodb_adaptive_hash_index=OFF试试——高并发小更新下AHI反而成争用点 - 避免在小事务里做
SELECT ... FOR UPDATE扫全表或范围大，换成更精准的索引条件 - 如果应用允许，把多个
INSERT/UPDATE合并成单条批量语句，比依赖组提交更高效
MySQL 5.7 vs 8.0 组提交行为差异
MySQL 8.0重写了binlog写入路径，引入了独立的binlog cache线程池和更激进的组提交策略。5.7的组提交只在flush阶段聚合，而8.0在write阶段就能开始攒批，整体延迟更低、吞吐更稳。
但这也带来新坑：8.0默认启用binlog_transaction_dependency_tracking=WRITESET，用于并行复制，但它会为每个事务计算writeset哈希，增加CPU开销。小事务多时，这个计算本身可能反成瓶颈。
- 如果不用MGR或并行复制，建议显式设为
COMMIT_ORDER，减少哈希计算压力 - 5.7升级到8.0后TPS不升反降，先检查
Performance_schema里的events_stages_history_long，过滤stage/sql/committing to binary log耗时 - 8.0.26+支持
binlog_group_commit_sync_delay动态修改，但改完需等当前批次完成才生效，不能立竿见影
组提交不是开关一开就万事大吉的银弹。它高度依赖事务执行效率、锁粒度、硬件IO能力三者的配合。最容易被跳过的其实是“先让单个事务变快”，而不是急着调sync_binlog。很多线上问题，最后发现是某条update语句没走索引，导致锁住了整片二级索引页，组提交自然失效。
