innodb_flush_log_at_trx_commit=0 确实能提速，但 MySQL 崩溃或断电时最近 1 秒内提交的事务全丢；适用于日志埋点等可重放场景，需配合调大 log buffer 和 log file size 并确认磁盘为启用 barrier 的 SSD。
innodb_flush_log_at_trx_commit=0 真的能提速？
能，但代价是事务可能丢——不是“大概率丢”，而是“只要 MySQL 崩溃或断电，最近 1 秒内提交的事务全丢”。innodb_flush_log_at_trx_commit 设为 0 时，事务提交不写磁盘，只写内存中的 log buffer，由后台线程每秒刷一次到 ib_logfile。这在写多读少、允许少量数据丢失的场景（比如日志埋点、行为采集）确实有效。
常见错误现象：SHOW ENGINE INNODB STATUS 里看到大量 log writes 等待，或 innodb_log_waits 持续增长，说明 log buffer 频繁刷盘成了瓶颈。
-
0：最快，但崩溃丢失最多 1 秒数据；适用于非核心业务、可重放写入 -
1（默认）：每次COMMIT都 fsync 到磁盘，最安全，性能最差 -
2：写入 OS cache 即返回，不 fsync；崩溃时依赖 OS 不丢数据（一般可靠），比1快不少，比0安全
为什么不能只调这个参数就完事？
单独改 innodb_flush_log_at_trx_commit 很容易翻车，因为 InnoDB 日志子系统是联动的。比如 log buffer 太小（innodb_log_buffer_size 默认 16MB），即使设成 0，高频小事务仍会触发主动 flush；又比如 innodb_log_file_size 过小，log 文件频繁 checkpoint，反而卡住写入。
使用场景判断关键点：你写的“多”，是单条大事务（如批量 INSERT），还是高并发小事务（如每秒几千次 UPDATE）？前者更依赖 innodb_log_file_size 和 buffer pool，后者才真正受 innodb_flush_log_at_trx_commit 影响。
- 若用
0或2，建议把innodb_log_buffer_size提到32M～64M，减少内存刷出频率 -
innodb_log_file_size总和建议 ≥ 1GB（如两个文件各 512MB），避免 checkpoint 过于频繁 - 确认磁盘是 SSD，且挂载时没禁用 write barrier（如
mount -o barrier=1）；否则2的安全性会打折扣
如何验证调参后是否真有效？
别只看 QPS 上升，重点盯三个指标：事务响应时间分布、innodb_log_waits 是否归零、以及磁盘 I/O 的 await 和 %util（用 iostat -x 1）。如果 await 明显下降但 innodb_log_waits 还在涨，说明 log buffer 或 log file size 成了新瓶颈。
实操建议直接查状态：
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_log_waits';
再对比调整前后每秒的 Com_commit 和 Innodb_os_log_written（单位字节），能看出日志写入是否更平滑。
-
Innodb_log_waits > 0表示 log buffer 不够用，必须调大innodb_log_buffer_size -
Innodb_os_log_written突增但吞吐没涨，可能是事务变大或锁冲突加剧，和 flush 参数无关 - 用
pt-stalk抓高负载时的SHOW ENGINE INNODB STATUS，重点关注 LOG SECTION 里的log sequence number和log flushed up to差值
MySQL 8.0+ 的隐藏风险：组提交（group commit）被削弱
MySQL 5.6–5.7 在 innodb_flush_log_at_trx_commit=1 下靠 group commit 缓解 fsync 压力，但 8.0 默认启用了 binlog_order_commits=ON，强制 binlog 和 innodb commit 串行，相当于废掉了大部分 group commit 效果。结果就是：即使设成 1，性能也可能比 5.7 差 20%～30%。
如果你用的是 MySQL 8.0+ 且无法接受 0 或 2，唯一办法是关掉 binlog 组提交（仅限无主从、无备份需求的场景）：
SET GLOBAL binlog_order_commits = OFF;
但注意：这会导致主从延迟波动加大，且 crash safe 机制弱化。
- 该变量动态生效，但只影响新连接；已有连接需重连才生效
- 必须配合
sync_binlog=1使用才有意义，否则关了也没差别 - 线上环境严禁在高峰期执行，它会短暂阻塞所有事务提交
真正难的从来不是改哪个数字，而是搞清你的“写多”，到底卡在哪一层：是磁盘吞吐、日志刷盘节奏、还是事务粒度本身。参数只是杠杆，支点错了，再用力也撬不动。
