“双1参数”指innodb_flush_log_at_trx_commit=1和sync_binlog=1，分别控制redo log与binlog每次事务提交均fsync落盘，共同保障金融级数据不丢失。
什么是“双1参数”，它们分别控制什么
MySQL 的“双1参数”指 innodb_flush_log_at_trx_commit=1 和 sync_binlog=1。这两个配置共同决定事务提交后日志是否真正落盘，是金融级数据不丢失的底线保障。
前者控制 InnoDB redo log 的刷盘行为：设为 1 表示每次事务提交都调用 fsync() 将 log buffer 写入磁盘；设为 0 或 2 会缓存或仅写入 OS page cache，断电即丢。
后者控制 binlog 的同步策略：设为 1 表示每次事务提交都对 binlog 文件执行 fsync()；若为 0，则依赖 OS 刷盘（不可控），为 N（N>1）则每 N 次提交刷一次，存在窗口期丢失风险。
为什么必须同时设为1，只设一个不行
只开 innodb_flush_log_at_trx_commit=1 但 sync_binlog=0：主库 crash 后，redo log 是完整的，但 binlog 可能缺失部分事务。这会导致基于 binlog 的恢复、主从复制、闪回等全部失效——因为 binlog 是逻辑日志，是 MySQL 外部一致性的唯一凭证。
只开 sync_binlog=1 但 innodb_flush_log_at_trx_commit=0：binlog 已落盘，但 InnoDB 层的 redo log 还在内存里。此时 crash，InnoDB 启动时无法重做该事务，造成 binlog 有记录而引擎没数据，主从数据不一致，甚至导致从库复制中断（报错 “Could not execute Write_rows event on table…”）。
二者必须同时为 1，才能保证“事务提交 → redo log 落盘 → binlog 落盘”原子性闭环。
开启双1后性能下降明显，怎么缓解
双1带来最直接代价是每次事务提交都要两次 fsync()（redo + binlog），在高并发小事务场景下 IOPS 压力陡增。缓解不是靠降配置，而是分层优化：
- 确保 MySQL 使用的是带掉电保护（PLP）的企业级 NVMe SSD，避免普通 SATA SSD 或机械盘成为瓶颈
- 将
innodb_log_file_size调大（如 2G～4G），减少 log checkpoint 频率，降低 redo 写放大 - 确认
binlog_format=ROW（必须），避免 MIXED 或 STATEMENT 格式引入不确定性 - 应用层尽量合并事务：例如将 10 次单行 UPDATE 改为 1 次多值 INSERT … ON DUPLICATE KEY UPDATE，减少提交次数
- 禁用
innodb_doublewrite=OFF—— 绝对不要这么做。doublewrite 是防止页写半页的关键机制，和双1一样属于数据安全基线
验证双1是否真正生效且持久化
不能只查 SHOW VARIABLES，因为运行时修改不写入配置文件，重启即失效。必须确认两件事：
第一，配置已写入 my.cnf 并被加载：
grep -E "innodb_flush_log_at_trx_commit|sync_binlog" /etc/my.cnf
输出应为 innodb_flush_log_at_trx_commit = 1 和 sync_binlog = 1，且不在被注释行中。
第二，运行时值与配置一致：
SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('innodb_flush_log_at_trx_commit', 'sync_binlog');
结果必须均为 1。
第三，检查 error log 是否有警告：若启用了 skip_log_bin 或 binlog 被禁用，sync_binlog=1 实际无效，MySQL 会默默忽略并记录警告 “sync_binlog ignored because binary logging is disabled”。
最容易被忽略的是：某些云厂商 RDS 默认关闭 binlog 或使用自研日志替代，此时 sync_binlog 根本不生效——务必先确认 binlog 确实开启且格式正确。
