选1就别动，选2或0必须同步调sync_binlog，否则性能白优化、数据更危险；因sync_binlog=1会触发redo与binlog双刷盘，且老连接复用、autocommit未关、配置未写入my.cnf重启等均导致参数“假生效”，须验证Innodb_os_log_fsyncs每秒是否≈1。
选 1 就别动，选 2 或 0 必须同步调 sync_binlog，否则性能白优化、数据还更危险。
为什么改了 innodb_flush_log_at_trx_commit 却没提速？
常见错误现象：把 innodb_flush_log_at_trx_commit 改成 2 或 0 后，TPS 没涨，p99 延迟照样高。
- 根本原因不是参数没生效，而是
sync_binlog = 1（默认）还在抢磁盘——每次 COMMIT 实际触发两次刷盘（redo + binlog），innodb_flush_log_at_trx_commit = 2只省了一半 - 老连接复用导致“假生效”：动态执行
SET GLOBAL innodb_flush_log_at_trx_commit = 2后，已有连接仍按旧值运行，压测流量打在老连接上，看不出变化 - 验证方式必须盯
Innodb_os_log_fsyncs：执行SHOW GLOBAL STATUS LIKE 'Innodb_os_log_fsyncs';，观察每秒调用次数是否降到接近 1；光看 TPS 或延迟会被缓存/网络掩盖
innodb_flush_log_at_trx_commit = 0 为什么 INSERT 还慢？
典型误用场景：设成 0 后单条 INSERT 依然卡顿，误以为参数失效。
-
innodb_flush_log_at_trx_commit = 0只在显式事务中起效，对自动提交的单条语句无效——因为每条INSERT都是独立事务，仍走默认日志路径 - 必须先关自动提交：
SET autocommit = 0;，再批量执行：INSERT INTO t VALUES (),(),();，最后COMMIT; - 否则即使参数是 0，每条语句仍触发 log buffer 写入逻辑（只是不 fsync），I/O 压力没真正释放
生产环境怎么写配置才真正生效？
动态 SET 是临时补丁，不是上线方案。
- MySQL 8.0+ 不支持
SET PERSIST修改该参数，必须写进配置文件并重启 - 配置写法必须是整数且无引号：
innodb_flush_log_at_trx_commit = 2（不能写成"2"或2L） - 必须放在
[mysqld]段下，写错段落（如[client]）会导致静默忽略 - 改完必须验证：
SHOW GLOBAL VARIABLES LIKE 'innodb_flush_log_at_trx_commit';，确认值已更新，且重启后仍保持
最容易被忽略的是硬件层风险：哪怕设成 2，如果磁盘启用了 write cache 且没电池保护（BBWC），OS 缓存里的日志可能根本没机会刷盘就断电丢失。这不是 MySQL 能管的事，但你得知道边界在哪。
