SQL innodb_flush_log_at_trx_commit=1 的耐久性与写延迟权衡

是的，但仅保证redo log刷至磁盘日志文件，不保证绕过os/磁盘缓存；需配合sync_binlog=1等才能实现强一致。

innodb_flush_log_at_trx_commit=1 真的保证“每次提交都落盘”吗？

是的，但只限于 log buffer 刷到 OS cache 并调用 fsync() 写入磁盘日志文件（ib_logfile0 等）——不是刷数据页，也不是刷 binlog。它不保证操作系统或磁盘固件没缓存，也不绕过存储栈的写缓存（比如 RAID 卡、NVMe 的 write cache）。如果磁盘掉电且未禁用写缓存，仍可能丢最后几条事务。

• 必须配合 sync_binlog=1 + binlog_format=ROW 才能支撑主从强一致或崩溃恢复后 binlog 与 InnoDB 一致
• 若使用云盘（如 AWS gp3、阿里云 ESSD），需确认其提供“持久化写入语义”，部分共享型存储会延迟透传 fsync()
• 某些 SSD 在断电保护失效时（电容老化），fsync() 返回成功但实际未落盘

为什么设成 2 或 0 后写性能明显提升？

因为跳过了每事务一次的 fsync() 系统调用：设为 2 是刷到 OS cache（异步、快），设为 0 连 OS cache 都不刷（只留内存 log buffer，最危险）。瓶颈不在 mysql，而在磁盘 I/O 调度和物理写入延迟 —— 尤其高并发小事务场景下，fsync() 成为串行点。

• innodb_flush_log_at_trx_commit=1 下，TPS 常被压在 100–500（普通 SATA SSD），而 =2 可达 3000+，差距来自系统调用开销和磁盘队列竞争
• =0 虽快，但 MySQL 崩溃会导致最近 1 秒所有事务丢失（log buffer 每秒刷一次），不适合任何生产 OLTP
• 注意：即使 =2，MySQL 崩溃不会丢事务，但主机断电仍可能丢 OS cache 中未刷盘的日志

什么时候可以安全地调低这个值？

仅当业务可接受“主机断电丢失最多 1 秒事务”的场景，且已放弃单机强耐久性目标。典型如日志类、埋点、实时推荐特征缓存等最终一致性系统。

• 不能用于支付、账务、库存扣减等需要 ACID 强保障的模块
• 若用 MGR 或基于 GTID 的异步复制，=2 会导致主库崩溃后从库多出未提交事务（因 binlog 已写但 redo 未落盘），引发数据不一致
• 监控上要盯住 Innodb_os_log_pending_fsyncs：该值持续 > 0 表示 fsync() 被阻塞，可能是磁盘过载，此时降级 =2 只是掩盖问题，不是解法

如何验证当前配置是否真正在起作用？

别只看 SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit'，得测行为。最直接方式是模拟事务提交后立刻 kill -9 mysqld，再重启看数据是否回滚。

• 用 strace -e trace=fsync,write -p $(pidof mysqld) 观察是否每个 COMMIT 都触发 fsync()（=1 时应高频出现；=2 时几乎不出现）
• 检查 /proc/sys/vm/dirty_ratio 和 /proc/sys/vm/dirty_expire_centisecs：linux 回写策略会影响 =2 下日志在 OS cache 中停留时间
• 云环境务必查文档：AWS RDS 默认强制 =1 且不可改；阿里云 PolarDB 允许改但底层用共享存储，fsync() 行为与本地盘不同

事情说清了就结束。真正卡住人的从来不是参数值本身，而是没想清楚“我的数据到底怕什么”——怕 MySQL 崩溃？怕主机断电？怕云厂商存储故障？还是怕主从不一致？选错一档，补救成本远高于一开始画清边界。