值为1是金融/订单类系统唯一可选方案，确保MySQL崩溃、OS崩溃或断电时已提交事务不丢失；设为2需配sync_binlog=1000或0，设为0仅在autocommit关闭且批量事务中生效。
值为 1 是金融/订单类系统唯一可选方案
设成 innodb_flush_log_at_trx_commit = 1 不是“保守选择”，而是 ACID 持久性的硬性底线。MySQL 崩溃、OS 崩溃、突然断电——只要事务返回成功，数据就一定在磁盘上。
实测在 SATA SSD 上单次 COMMIT 延迟约 0.5–2ms；HDD 可能飙到 10–30ms，高并发下 iowait 明显升高。这不是配置问题，是物理限制。
- 别指望靠调大
innodb_log_buffer_size来缓解：它只减少 buffer 争用，不改变 fsync 频次 - 若开了 binlog（主从/GTID 必开），必须同步设
sync_binlog = 1，否则 redo 和 binlog 落盘不同步，GTID 可能跳变 - 硬件跟不上时，优先升级存储（带 BBWC 的 RAID 卡或 NVMe SSD），而不是降级该参数
设成 2 必须配对调整 sync_binlog
innodb_flush_log_at_trx_commit = 2 单独改没用，它只保证 MySQL 进程挂了不丢数据；但 OS 崩溃或断电仍会丢最多 1 秒事务。这时候如果 sync_binlog = 1，binlog 已落盘而 redo log 还卡在 OS cache，主从复制会出 GTID gap 或无法追平。
真正起效的组合只有两种：
-
innodb_flush_log_at_trx_commit = 2+sync_binlog = 1000：每 1000 次 COMMIT 刷一次 binlog，性能提升明显，适合 ERP、用户行为日志等场景 -
innodb_flush_log_at_trx_commit = 2+sync_binlog = 0：完全依赖 OS 刷盘，风险是 binlog 可能比 redo 少几条，仅限可容忍 GTID 跳变的非关键链路
别信“设成 2 就能提 5 倍 TPS”——压测时若没关连接池复用，老连接仍按旧值跑，结果全是假象。
值为 0 仅限批量导入且 autocommit 必须关
innodb_flush_log_at_trx_commit = 0 对单条 INSERT 几乎无效。因为默认 autocommit = 1，每条语句都是独立事务，仍触发 write() 调用（只是不 fsync）。
它只在显式事务里生效，且必须满足两个条件：
- 先执行
SET autocommit = 0 - 再用
INSERT INTO t VALUES (),(),()批量语法，最后COMMIT
否则即使参数是 0，Innodb_os_log_fsyncs 每秒仍可能高达几百次——你根本没绕过刷盘逻辑。
上线前务必关掉 UNIQUE_CHECKS 和 FOREIGN_KEY_CHECKS，否则索引校验本身就会拖慢速度，让 0 的优势全白费。
验证是否真生效，盯紧 Innodb_os_log_fsyncs
别只看 TPS 或 p99 延迟：这些指标被缓存、网络、应用层层层掩盖，根本反映不了底层日志行为。
真实情况看 MySQL 自身统计：
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_fsyncs';
这个值每秒调用次数才是铁证：
- 值为 1 → 应 ≈ 当前每秒事务数（如 1200 TPS，则 fsyncs ≈ 1200）
- 值为 2 → 应 ≈ 1（操作系统后台每秒 flush 一次）
- 值为 0 → 也 ≈ 1，但
Innodb_os_log_written增速会明显滞后
动态 SET 后不验证，等于没改；写进 my.cnf 不重启，等于白写；重启后不查这个状态变量，等于赌运气。
