MySQL组提交默认开启但实际效果受限于innodb_flush_log_at_trx_commit=1导致每事务强制fsync，无法合并持久化；设为2可聚合日志并单次刷盘，配合sync_binlog=1000及OS层调度优化（如noop、禁barrier）才能真正生效。
MySQL 默认开启组提交（Group Commit），但大量小事务仍压垮 IO，根本原因不是它没开，而是日志刷盘频率和底层存储响应不匹配。
innodb_flush_log_at_trx_commit = 1 时，组提交实际效果受限
即使启用了组提交，当 innodb_flush_log_at_trx_commit 设为 1，每个事务提交都必须调用一次 fsync() 刷 Redo Log 到磁盘。此时组提交只能把多个事务的日志缓冲区（log buffer）合并写入 log file，但无法合并 fsync 操作——操作系统或磁盘仍需对每次写入做持久化确认。
- SSD 上单次
fsync延迟通常在 0.1–0.5ms，1000 TPS 就意味着每秒至少 1000 次强制刷盘 - 机械盘更糟，单次
fsync可达 5–10ms，200 TPS 就可能打满磁盘 I/O 队列 -
SHOW ENGINE INNODB STATUS\G中若看到Log sequence number增长平滑但fsyncs数值飙升，就是这个现象
如何让组提交真正起效：放宽刷盘时机
组提交要发挥价值，必须允许日志先批量写入文件系统缓存，再由后台线程统一刷盘。关键在于降低 fsync 频率，同时控制数据丢失窗口。
- 设
innodb_flush_log_at_trx_commit = 2：事务提交只写入 OS cache，由后台每秒一次的log write线程刷盘 —— 此时组提交能真正聚合多事务日志并单次fsync - 搭配
sync_binlog = 1000（而非默认 1）：Binlog 也延迟同步，避免双日志各自刷盘放大 IO - 注意：
innodb_flush_log_at_trx_commit = 0虽然更快，但崩溃可能丢最多 1 秒全部事务，生产环境慎用
验证组提交是否生效：看 log_writes 和 log_fsyncs 的比值
执行 SHOW GLOBAL STATUS LIKE 'Innodb_log%';，重点关注两个指标：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
Innodb_log_writes：Redo 日志写入次数（含缓存写入） -
Innodb_log_fsyncs：实际调用fsync()的次数
理想情况下，Innodb_log_fsyncs / Innodb_log_writes 应显著小于 1（比如 0.01～0.1）。如果两者接近 1:1，说明几乎每个写都在触发 fsync，组提交被架空。
容易被忽略的底层限制：文件系统与磁盘调度器
即使参数调对，组提交也可能被 OS 层“拆散”：
- 使用
ext4且挂载选项含barrier=1（默认），每次write()后会隐式加屏障，抵消组提交收益 - 磁盘调度器设为
cfq或bfq时，IO 请求可能被拆分调度，破坏合并效果；SSD 应设为none或noop -
innodb_flush_method = O_DIRECT可绕过 page cache，但会削弱组提交的缓冲聚合能力；高并发小事务场景下，O_DSYNC或默认值反而更稳
真正压测时，别只盯着 MySQL 参数，iostat -x 1 里看 avgqu-sz（平均队列长度）和 await（平均等待时间）突变点，往往暴露的是 OS 或硬件层的瓶颈。
