innodb_flush_log_at_trx_commit没有“平衡”的魔法值，只有根据崩溃场景和业务容忍度做的明确取舍：值为1可扛断电不丢数据，是acid持久性底线；值为2在mysql崩溃时保数据但os崩溃会丢1秒；值为0性能最高但三类崩溃均可能丢失最多1秒事务。
innodb_flush_log_at_trx_commit 没有“平衡”的魔法值，只有根据崩溃场景和业务容忍度做的明确取舍。设为 1 是唯一能扛住断电不丢数据的配置；设为 2 或 0 都意味着你接受了某种确定性的丢失边界。
值为 1：金融/订单类系统必须用，别犹豫
每次 COMMIT 都触发 fdatasync() 到磁盘，MySQL 崩溃、OS 崩溃、突然断电——已提交事务全部保留。这不是“更安全”，而是 ACID 持久性的底线要求。
- SSD 上单次延迟约 0.5–2ms；HDD 可能飙到 10–30ms，高并发下
iowait明显升高 - 不能只靠调大
innodb_log_buffer_size来缓解——它只减少小事务对 buffer 的争用，不改变 fsync 频次 - 若搭配
sync_binlog = 1（即“双1”），主从一致性最强，但写入吞吐常下降 40%+，需确认硬件是否撑得住
值为 2：MySQL 崩溃保命，但 OS 崩溃或断电会丢数据
每次 COMMIT 只调用 write() 进 OS page cache，fsync 由内核后台线程每秒执行一次。这是多数非核心写入最现实的折中点。
- MySQL 进程挂了？数据全在；主机突然断电？最多丢上一秒内所有
COMMIT的事务 - 实测在 SATA SSD 上，TPS 从 2400（值为 1）升至约 12000，IOPS 从 200MB/s 降到 10MB/s
- 务必检查
sync_binlog是否错配：若设为sync_binlog = 1而innodb_flush_log_at_trx_commit = 2，binlog 已落盘但 redo log 还卡在 OS cache，主从 GTID 可能跳变
值为 0：仅限可重刷、非实时场景，上线前必须关 autocommit
事务提交时完全不碰日志 buffer，全靠 InnoDB 后台线程每秒 flush 一次。性能最高，但风险也最不可控。
- MySQL 崩溃、OS 崩溃、断电——三者任一发生，都可能丢掉整个上一秒的 redo log（默认 16MB buffer）
- 单独改
innodb_flush_log_at_trx_commit = 0几乎无效：必须配套SET autocommit = 0，否则每条INSERT仍是独立事务，仍走默认刷盘逻辑 - 批量导入时建议再关
UNIQUE_CHECKS和FOREIGN_KEY_CHECKS，否则索引校验本身就会拖慢速度
验证时最容易被忽略的监控项
别只看 TPS 或延迟，关键要看 Innodb_os_log_fsyncs 每秒调用次数：值为 1 时它应≈每秒事务数；值为 2 时应≈1；值为 0 时也≈1，但 Innodb_os_log_written 增速会明显滞后。这些指标比任何文档描述都真实反映底层行为。
