“双1设置”即innodb_flush_log_at_trx_commit=1且sync_binlog=1，是mysql掉电场景下保障已提交事务不丢失、主从一致和可归档恢复的最低安全底线，缺一不可。
innodb_flush_log_at_trx_commit=1 是掉电不丢数据的底线
掉电场景下，只有 innodb_flush_log_at_trx_commit=1 能真正保证已提交事务不丢失。这个值强制每次 COMMIT 都把 redo log 从 buffer 直接 fsync 到磁盘，绕过操作系统 page cache。其他两个值都存在风险：
-
0：仅靠后台线程每秒刷一次，掉电可能丢失最多 1 秒内所有已提交事务 -
2：日志写入 page cache 后就返回成功，依赖 OS 刷盘——但掉电时 page cache 未落盘的数据会彻底消失
注意：即使设为 1，也不能完全无视硬件。如果磁盘控制器开了写缓存且没用电池/电容保护，或者系统禁用了 barrier 或用了 hdparm -W0 关闭磁盘缓存，fsync 可能被“假成功”，实际日志还在磁盘缓存里。
为什么单设 innodb_flush_log_at_trx_commit=1 还不够
MySQL 持久化依赖两套日志协同：redo log 保崩溃恢复，binlog 保主从一致和归档恢复。只保 redo log 不丢，不代表 binlog 也安全。若 sync_binlog != 1，掉电后可能出现：
- 事务已提交、redo log 已落盘 → 数据页可恢复
- 但对应 binlog 还卡在 page cache 或根本没写 → 主从同步中断、无法用 binlog 增量恢复
所以生产环境掉电防护必须配对设置：innodb_flush_log_at_trx_commit=1 且 sync_binlog=1，即所谓“双1”。否则会出现数据页可恢复但复制链断裂、备份不可用的问题。
动态修改 innodb_flush_log_at_trx_commit 的真实效果
该参数支持运行时修改，执行 SET GLOBAL innodb_flush_log_at_trx_commit = 1 立即生效，无需重启。但要注意：
- 修改后只影响新开启的事务，正在执行中的事务仍按旧策略走
- 若之前长期是 0 或 2，突然切到 1，TPS 可能下降 20%~40%，尤其在高并发小事务场景（如订单支付）
- 某些云厂商 MySQL 实例（如腾讯云 CDB）默认限制该参数为只读，需在控制台开启“高可靠模式”或提工单解锁
建议先在低峰期验证：用 sysbench 对比修改前后 oltp_point_select 和 oltp_update_non_index 的延迟分布，重点关注 p99 是否突增。
容易被忽略的硬件与 OS 层依赖
哪怕参数全设为 1，掉电不丢数据仍不是自动成立的。关键依赖链上有三个常被跳过的环节：
- 文件系统挂载选项：必须含
data=ordered（ext4）或mount -o sync（XFS），禁用noatime不影响，但barrier=0会直接废掉fsync语义 - 磁盘写缓存：消费级 SATA SSD 默认开启写缓存，掉电必丢；需用
smartctl -l scterc /dev/sdX查看，用hdparm -W0 /dev/sdX关闭（仅限有断电保护的盘） - MySQL 启动参数：确认没加
--skip-innodb-doublewrite或--innodb-flush-method=O_DSYNC这类绕过安全路径的选项
最隐蔽的问题是：有些 NVMe 盘固件声称支持 flush，但实测掉电后 page cache 里的数据仍会丢失——这时只能换企业级盘或接受 1 秒 RPO。
