设为1时每次commit都触发fsync，磁盘延迟导致提交卡顿；设为2可写入os缓存后立即返回，兼顾性能与安全性，崩溃最多丢1秒事务。
innodb_flush_log_at_trx_commit 设为 1 是事务提交慢的最常见直接原因，尤其在机械盘、低 IOPS 云盘或高并发写入场景下。这不是配置错误，而是安全与性能的权衡点——你得先确认业务是否真需要每条事务都“落盘即稳”。
为什么设为 1 就会卡住 COMMIT
这个参数控制 InnoDB redo log 的刷盘时机。值为 1 时，每次 COMMIT 都触发一次 fsync() 到磁盘；而磁盘（尤其是非 NVMe）的 fsync 延迟常在几毫秒到几十毫秒，高并发下迅速堆积。你看到的“提交慢”，其实是线程在等磁盘响应。
常见现象包括：
-
SHOW ENGINE INNODB STATUS中LOG段显示pending log writes或pending log flushes不为 0 - 监控里
io_wait占比突增，CPU 和内存却很空闲 - 单条
INSERT很快，但COMMIT耗时占整个事务 80% 以上
设成 2 是最实用的折中方案
值为 2 表示 redo log 写入操作系统缓存（page cache）就返回成功，由 OS 异步 fsync。崩溃最多丢 1 秒内未刷盘的事务，但提交延迟几乎归零。
注意这不等于“不安全”——只要 sync_binlog 配合得当，仍能保证 crash-safe（InnoDB prepare 阶段已写 binlog）：
- 若没开 binlog，
innodb_flush_log_at_trx_commit=2即可单独生效 - 若开了 binlog，建议同步设
sync_binlog=1000（MySQL 5.7.7+ 支持），避免两次fsync叠加 - 不要只改这个参数却不查
sync_binlog：两者组合才决定最终一致性边界 - 某些云厂商 RDS 默认锁定该参数，需进管控台确认是否允许修改
别踩这些坑
调参不是改完就完事，容易忽略的关键点：
-
autocommit=0被 ORM 或连接池静默关闭，导致你以为在自动提交，实际所有 DML 都堆在长事务里——先查SELECT @@autocommit; - 应用层事务未显式
COMMIT或ROLLBACK，异常路径遗漏回滚，连接复用时携带未结束事务，锁持续占用 - 批量插入仍用循环单条
INSERT，哪怕autocommit=1，也等于每行都触发一次 redo + binlog 写入；应改用多值INSERT INTO ... VALUES (),(),() - 大事务（如单次更新 >1 万行）即使参数调优也难救——锁升级、undo 日志膨胀、从库复制延迟都会恶化，必须拆分
真正起效前先确认底层 IO 是否拖后腿
就算 innodb_flush_log_at_trx_commit=2，如果磁盘本身响应慢（比如云盘 IOPS 饱和、IO 调度器不合理），OS 缓存异步刷盘也会排队，照样拖慢整体吞吐。
建议同步检查：
-
iostat -x 1看%util和await是否持续高位 - 文件系统是否用
ext4（而非xfs）且挂载选项含barrier=1（部分旧内核会加重延迟） - 磁盘调度器是否为
deadline或none（SSD/NVMe 推荐none）
参数调优只是链条一环，IO 底层不稳，上层再怎么折中也白搭。
