innodb_flush_log_at_trx_commit=1承诺断电不丢已提交事务，=2接受OS崩溃最多丢1秒数据，=0则MySQL崩溃也可能丢失；必须写入my.cnf并重启生效，且需配合sync_binlog、autocommit等参数协同调优。
innodb_flush_log_at_trx_commit 不是“调优开关”，而是明确的数据保护承诺——设成 1 就代表你要求断电也不丢已提交事务；设成 2 就等于接受 OS 崩溃时最多丢 1 秒数据；设成 0 则连 MySQL 崩溃都可能丢。选哪个，取决于你敢不敢为这 1 秒担责。
怎么改才真正生效：配置文件 vs 动态 SET
动态执行 SET GLOBAL innodb_flush_log_at_trx_commit = 2 立刻生效，但只影响新连接；老连接仍按旧值行为运行，重启后失效。生产环境必须写进配置文件（my.cnf 的 [mysqld] 段），然后重启 MySQL —— 否则上线后压测发现延迟没降，大概率是连接复用导致的“假配置”。
- 配置文件写法必须是整数，不能带引号：
innodb_flush_log_at_trx_commit = 2 - MySQL 8.0+ 不支持在线热改该参数（
SET PERSIST会报错），只能靠重启 - 改完别忘了验证：
SHOW GLOBAL VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
为什么设成 2 还卡在 I/O：别漏掉 sync_binlog
单独调 innodb_flush_log_at_trx_commit 是半截优化。如果开了 binlog（主从、GTID 场景必开），sync_binlog 也在抢磁盘：默认 sync_binlog = 1，每次 COMMIT 都要刷两次盘（redo + binlog），性能直接打对折。
- 搭配
innodb_flush_log_at_trx_commit = 2，建议设sync_binlog = 1000或sync_binlog = 0 -
sync_binlog = 0表示依赖 OS 刷盘，风险是 binlog 可能比 redo log 少几条，主从 GTID 跳变 - 若必须强一致（如金融核心），就别动
innodb_flush_log_at_trx_commit，老老实实用1+sync_binlog = 1
值为 0 时 INSERT 还慢？autocommit 没关
innodb_flush_log_at_trx_commit = 0 对单条自动提交的 INSERT 几乎无效——因为每条语句都是独立事务，仍走默认日志路径。它只在显式事务里起作用。
- 必须先执行
SET autocommit = 0，再批量INSERT，最后COMMIT - 否则即使参数是 0，每条
INSERT仍触发 redo log buffer 写入逻辑（只是不 fsync） - 配合
INSERT INTO t VALUES (),(),()...批量语法，才能把刷盘压力压到每秒一次
验证到底有没有生效：盯紧 Innodb_os_log_fsyncs
别光看 TPS 或 p99 延迟，这些指标会被缓存、网络、应用层掩盖。真实行为看 MySQL 自身统计：
-
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_fsyncs';—— 每秒调用次数：值为 1 时 ≈ 每秒事务数；值为 2 或 0 时应稳定在 ~1 -
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written';—— 每秒写入字节数：值为 2/0 时增速应明显平滑，不再随事务陡增 - 如果
Innodb_os_log_fsyncs每秒几百次，说明参数根本没生效，或被其他配置（如sync_binlog）覆盖了
最常被忽略的是：这个参数不是孤立存在的，它和 innodb_log_file_size、innodb_io_capacity、甚至硬件是否启用 write cache 密切相关。没配好 innodb_log_file_size，设成 2 也会因 checkpoint 频繁而卡住写入链路——参数调了，但底层日志循环跑不起来，一切白搭。
