innodb_flush_log_at_trx_commit=2是最直接有效的高频小事务优化配置，它将每事务刷盘降为每秒一次，iops压力下降80%以上，mysql崩溃不丢数据，仅os崩溃或断电可能丢失最多1秒redo日志；默认值1导致每个commit触发fdatasync，tps超200后磁盘%util长期100%，innodb_os_log_pending_fsyncs持续>0、innodb_log_waits增长、连接卡在updating状态；组提交需sync_binlog=100与该参数配合，通过binlog_group_commit_trigger_count非零验证生效；应用层须禁用autocommit、批量攒批（100~500行/事务）、剥离非dml操作；配套需调大innodb_log_file_size（建议4gb~8gb）、设innodb_log_files_in_group=2、redo log独立挂ssd、buffer_pool_size设为物理内存70%~80%。
innodb_flush_log_at_trx_commit=2 是高频小事务写入场景下最直接有效的配置调整，它把每事务一次刷盘降为每秒一次，IOPS 压力通常能下降 80% 以上，且 MySQL 进程崩溃不丢数据，仅 OS 崩溃或断电可能丢失最多 1 秒 redo 日志。
为什么小事务多时默认配置会卡住磁盘？
默认 innodb_flush_log_at_trx_commit=1 意味着每个 COMMIT 都触发一次 fdatasync()。TPS 超过 200 后，大量 4KB~16KB 的小刷盘请求排队，%util 长期 100%，await 拉高，但实际吞吐很低。典型现象包括：Innodb_os_log_pending_fsyncs 持续 > 0、Innodb_log_waits 每秒增长、SHOW PROCESSLIST 中大量连接卡在 Updating 状态。
怎么验证组提交是否真正生效？
组提交不是靠“开了 binlog”就自动起效的，它依赖 sync_binlog 和 innodb_flush_log_at_trx_commit 的组合：
-
sync_binlog=1且innodb_flush_log_at_trx_commit=1→ 组提交失效，变串行刷盘 - 推荐搭配：
sync_binlog=100+innodb_flush_log_at_trx_commit=2，兼顾安全与聚合效果 - 查
SHOW GLOBAL STATUS LIKE 'Binlog_group_commit_trigger_count'：非零说明有聚合；若该值几乎不涨但Binlog_group_commit_trigger_lock_wait猛增，说明事务被锁阻塞，组提交根本没机会启动
应用层必须同步做的三件事
光改参数不够，应用层不配合，性能提升会打折扣：
- 禁用自动提交：
SET autocommit = 0，显式用BEGIN/COMMIT控制边界 - 批量攒批：单次事务控制在 100~500 行（视单行大小调整），避免事务过大导致锁竞争或 undo 日志膨胀
- 剥离非必要操作：事务内只放
INSERT/UPDATE/DELETE，日志打印、HTTP 调用、SELECT 查询一律移出事务外
容易被忽略的配套调优点
innodb_flush_log_at_trx_commit=2 单独生效的前提是 redo log 容量足够大，否则 checkpoint 会频繁触发脏页刷新，IO 压力从 redo 转移到 data file：
-
innodb_log_file_size至少设为 512MB（总容量建议 4GB~8GB），需停库重建 -
innodb_log_files_in_group设为 2，避免单文件瓶颈 - redo log 目录单独挂 SSD/NVMe，避免和数据文件争 I/O
- 确认
innodb_buffer_pool_size足够大（物理内存 70%~80%），减少随机读放大写压力
