MySQL中如何处理高频的小事务写入？

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 的组合：

1. sync_binlog=1 且 innodb_flush_log_at_trx_commit=1 → 组提交失效，变串行刷盘
2. 推荐搭配：sync_binlog=100 + innodb_flush_log_at_trx_commit=2，兼顾安全与聚合效果
3. 查 SHOW GLOBAL STATUS LIKE 'Binlog_group_commit_trigger_count'：非零说明有聚合；若该值几乎不涨但 Binlog_group_commit_trigger_lock_wait 猛增，说明事务被锁阻塞，组提交根本没机会启动

应用层必须同步做的三件事

光改参数不够，应用层不配合，性能提升会打折扣：

1. 禁用自动提交：SET autocommit = 0，显式用 BEGIN / COMMIT 控制边界
2. 批量攒批：单次事务控制在 100~500 行（视单行大小调整），避免事务过大导致锁竞争或 undo 日志膨胀
3. 剥离非必要操作：事务内只放 INSERT/UPDATE/DELETE，日志打印、HTTP 调用、SELECT 查询一律移出事务外

容易被忽略的配套调优点

innodb_flush_log_at_trx_commit=2 单独生效的前提是 redo log 容量足够大，否则 checkpoint 会频繁触发脏页刷新，IO 压力从 redo 转移到 data file：

1. innodb_log_file_size 至少设为 512MB（总容量建议 4GB~8GB），需停库重建
2. innodb_log_files_in_group 设为 2，避免单文件瓶颈
3. redo log 目录单独挂 SSD/NVMe，避免和数据文件争 I/O
4. 确认 innodb_buffer_pool_size 足够大（物理内存 70%~80%），减少随机读放大写压力

真正卡住高频小事务的，往往不是 SQL 写法，而是事务粒度、日志刷盘节奏和锁等待链。参数调完不验证、应用不改逻辑、redo log 不扩容，等于只拧松了一颗螺丝却没动整个传动轴。