MySQL“双1配置”指innodb_flush_log_at_trx_commit=1和sync_binlog=1同时启用，确保每次事务提交均强制redo log与binlog落盘，实现crash-safe，适用于金融等强一致性场景。
MySQL 的“双1配置”不是复制架构，也不是主从部署方案，而是两个关键持久化参数同时设为 1 的组合：innodb_flush_log_at_trx_commit=1 和 sync_binlog=1。 这是保障已提交事务不丢失的最严格落盘策略，适用于金融、支付、订单等对数据一致性零容忍的场景。
innodb_flush_log_at_trx_commit=1 是什么行为
这个参数控制 InnoDB redo log 的刷盘时机。设为 1 时，每次 COMMIT 都会触发一次 fsync()，强制将日志缓冲区内容写入并刷新到磁盘上的 ib_logfile* 文件中。
- 值为 0：每秒刷一次，崩溃可能丢失最多 1 秒事务
- 值为 1（双1必需）：每次提交都
fsync，崩溃不丢已提交事务 - 值为 2：写入 OS 缓存即返回，但不
fsync；OS 崩溃或断电仍可能丢数据
注意：innodb_flush_log_at_trx_commit=1 本身不能防止 binlog 丢失 —— 它只管 redo log，而 binlog 是 Server 层的日志，需要另一个参数配合。
sync_binlog=1 才能真正形成“双保险”
sync_binlog 控制 MySQL 二进制日志（binlog）的同步行为。只有当它也等于 1，才能确保每个事务的 binlog 记录也完成 fsync 到磁盘。
-
sync_binlog=0：完全依赖 OS 刷盘，性能最好，但崩溃可能丢失大量 binlog -
sync_binlog=1（双1必需）：每次事务提交后立即fsyncbinlog，与innodb_flush_log_at_trx_commit=1协同，实现 crash-safe -
sync_binlog=N (N>1)：每 N 次提交刷一次盘，有折中空间，但不再满足“双1”定义
如果只开 innodb_flush_log_at_trx_commit=1 而 sync_binlog=0，主库崩溃后虽然 InnoDB 数据没丢，但 binlog 可能缺失，导致基于 binlog 的恢复、复制或备份失效 —— 这就是单点脆弱性。
开启双1后必须注意的三个现实问题
双1不是“开了就万事大吉”，它的代价非常具体，且容易在压测或上线后才暴露：
- 磁盘 I/O 突增：每个事务引发至少 2 次
fsync（redo + binlog），SSD 尚可，HDD 下 QPS 可能腰斩 - 事务响应时间变长：
COMMIT耗时从微秒级升至毫秒级，尤其在高并发小事务场景下，应用层感知明显 - 依赖存储可靠性：即使双1开启，若底层文件系统（如 ext4）未禁用 write barrier，或 RAID 卡缓存未关闭写缓存（且无电池保护），仍可能绕过实际落盘
别忽略配置生效方式：innodb_flush_log_at_trx_commit 是动态变量，可运行时改；但 sync_binlog 在 MySQL 8.0.30+ 才支持动态修改，旧版本必须重启 mysqld 才生效。
怎么确认当前实例是否真正在跑双1
不能只看配置文件，得查运行时值。执行以下 SQL：
SELECT VARIABLE_NAME, VARIABLE_VALUE
FROM performance_schema.global_variables
WHERE VARIABLE_NAME IN ('innodb_flush_log_at_trx_commit', 'sync_binlog');
输出必须同时为：
-
VARIABLE_VALUE = '1'对应innodb_flush_log_at_trx_commit -
VARIABLE_VALUE = '1'对应sync_binlog
注意：sync_binlog 在某些云厂商 RDS 上被锁定为 1 或不可见，需查阅对应平台文档；而部分容器化部署可能因挂载方式绕过 fsync（如使用 :nocopy 或 tmpfs），这时双1形同虚设。
