innodb_flush_log_at_trx_commit=1 是 acid 中持久性（durability）的底线保障，因每次事务提交均强制 fsync 写入 redo 日志，断电也不丢已提交数据；设为 2 最多丢 1 秒数据，0 则可能破坏原子性且不保证崩溃恢复。
innodb_flush_log_at_trx_commit=1 为什么是 ACID 的底线
这个值设为 1 时，每次事务提交都强制刷盘日志（fsync 到 ib_logfile），确保即使断电，已提交事务的 redo 日志也已落盘——这是实现持久性（Durability）的硬性要求。mysql 官方文档明确说：只有 innodb_flush_log_at_trx_commit=1 才满足 ACID 中的 D。
常见错误现象：SET GLOBAL innodb_flush_log_at_trx_commit = 2 后业务没报错，但突然断电导致最近 1 秒内已 COMMIT 的订单丢失，用户查不到付款记录。
- 必须配合
sync_binlog=1才能保证主从一致性（否则 binlog 和 redo 可能不一致） - SSD 上单次
fsync延迟约 0.1–0.5ms；机械盘可能达 5–15ms，直接卡住高并发小事务 - 不是“越安全越好”——如果业务本身允许短暂数据丢失（如实时点击统计），
1就是过度保护
设成 2 时，到底丢什么、丢多久
值为 2 表示事务提交时只写入操作系统缓存（write），不调用 fsync；OS 每秒刷一次盘。这意味着：只要 MySQL 进程没崩，但机器断电或内核 panic，最多丢失 1 秒内的已提交事务。
使用场景：对延迟敏感、可容忍秒级丢失的业务，比如用户行为埋点、监控指标聚合、非关键配置更新。
- 注意：linux 的
vm.dirty_ratio和vm.dirty_expire_centisecs会影响实际刷盘时机，不能假设“严格每秒一次” - 和
innodb_flush_log_at_timeout无关——后者只控制后台线程刷 log buffer，不影响提交路径 - 主库设
2+ 从库设1是危险组合：主库 crash 后无法从 binlog 补齐那 1 秒，从库会比主库多出不可回滚的数据
设成 0 的真实风险：不只是丢数据
0 表示事务提交时连 OS 缓存都不写，日志留在 MySQL 自己的 log_buffer 里，依赖后台线程每秒刷一次。这会导致：崩溃时不仅丢全部未刷日志，还可能破坏事务原子性——比如一个事务修改了 3 行，只刷了前 2 行的日志，恢复后出现半截事务。
性能提升有限：现代 SSD 下，0 比 1 的吞吐提升通常不到 2×，但代价是彻底放弃 ACID 保证。
- MySQL 8.0.30+ 在
0模式下仍会定期刷盘，但间隔不可控，且不保证顺序 - 无法用于任何需要崩溃恢复的场景，包括普通主从复制（
CHANGE MASTER TO依赖可靠 binlog 位置） - 某些云厂商 RDS 默认禁止设
0，改了也会在重启后被覆盖
怎么选？看你的 WAL 路径和硬件瓶颈
别只盯着参数值，先确认日志实际写在哪：SHOW VARIABLES LIKE 'innodb_log_group_home_dir'。如果它和数据文件共用同一块 NVMe 盘，1 的延迟未必高；但如果日志放在慢速网络存储或混用机械盘，1 就真成瓶颈。
- 检查真实延迟：
select FILE_NAME, EVENT_NAME, TOTAL_TIMER_WAIT FROM performance_schema.file_summary_by_instance WHERE FILE_NAME LIKE '%ib_logfile%'; - 混合负载下，可以给关键事务显式加
SET session innodb_flush_log_at_trx_commit = 1，其他会话保持2 - 用
sys.schema_table_statistics查看innodb_log_waits：非零说明 log buffer 经常不够用，此时调大innodb_log_buffer_size比调低 flush 参数更有效
真正难的是平衡——不是参数数字本身，而是你能否清晰说出：“这笔钱必须不丢”，或者“这张表丢了就重跑”。磁盘故障率、备份策略、应用重试逻辑，全得串起来看。参数只是其中一环。