“双一机制”指sync_binlog=1且innodb_flush_log_at_trx_commit=1，二者缺一不可：仅前者为1而后者非1会导致主从不一致；仅后者为1而前者非1则崩溃后binlog丢失致复制中断；两者均为1才满足Crash-Safe Replication与GTID稳定运行前提，但性能显著下降。
MySQL 8.0 中没有“双一机制”这个官方术语，它其实是民间对 sync_binlog = 1 和 innodb_flush_log_at_trx_commit = 1 这两个参数的合称。只有这两个值同时为 1，才能在崩溃后最大程度保证已提交事务不丢失——但代价是写性能明显下降。
确认 innodb_flush_log_at_trx_commit=1（InnoDB 日志刷盘策略）
这个参数控制 InnoDB 的 redo log 是否在每次事务提交时强制刷到磁盘：
- 值为
1：最安全。每次COMMIT都触发fsync()，崩溃后不会丢已提交事务 - 值为
0或2：都可能丢事务。0 是每秒刷一次，2 是写入 OS 缓存但不fsync，断电即丢 - 检查命令：
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';，输出必须是1 - 动态设置无效（只读变量），必须写入
[mysqld]段并重启；或用SET PERSIST（需权限）
确认 sync_binlog=1（binlog 刷盘策略）
这个参数决定 binlog 是否同步写入磁盘，和上一个参数配合才构成完整持久性保障：
- 值为
1：每次事务提交都fsyncbinlog 文件，避免 binlog 缓存在 OS 中未落盘 - 值为
0：依赖 OS 刷盘，崩溃可能丢 binlog，导致主从不一致或恢复失败 - 值为
N>1：每 N 次提交刷一次，中间 crash 会丢最多 N-1 个事务的 binlog - 检查命令：
SHOW VARIABLES LIKE 'sync_binlog';，输出必须是1 - 可动态设置：
SET GLOBAL sync_binlog = 1;，但建议写入配置文件并重启，避免重启后失效
为什么两个都得是 1？缺一不可
单独设其中一个为 1 不够，因为 MySQL 提交事务是两阶段过程（prepare + commit），需要两个日志协同：
- 若
innodb_flush_log_at_trx_commit=1但sync_binlog=0：redo log 落盘了，但 binlog 还卡在 OS 缓存里。崩溃后 InnoDB 可恢复数据，但 binlog 缺失 → 主从复制中断、备份无法按位点恢复 - 若
sync_binlog=1但innodb_flush_log_at_trx_commit=0：binlog 写全了，但 redo log 没刷盘。崩溃后 MySQL 启动时回滚该事务（因 redo 无记录），但从库已执行 → 主从数据不一致 - 两者都是 1 才满足“Crash-Safe Replication”前提，也是 GTID 复制稳定运行的基础
性能影响与折中方案
两个 1 带来的是磁盘 I/O 压力倍增，尤其在高并发小事务场景下：
- 不要在 SSD 性能差或 I/O 已饱和的机器上盲目开启，先压测 TPS 下降幅度
- 如果业务允许极小概率丢事务（如日志类、埋点类），可考虑
innodb_flush_log_at_trx_commit=2+sync_binlog=1，但必须接受断电丢最近 1 秒事务的风险 -
sync_binlog=1对 binlog 文件所在磁盘有强依赖，务必确保该路径不在系统盘或低速 RAID 0 上 - 启用
binlog_group_commit_sync_delay（8.0.26+）可缓解压力：允许最多延迟 100 微秒攒一批事务一起刷盘，微损一致性换吞吐
真正难的不是配这两个 1，而是确认它们生效后，你的存储设备是否真能扛住持续 fsync。很多线上故障不是参数没设对，而是磁盘响应超时导致 MySQL 主动 kill 自己的写线程。上线前务必用 fio 测过目标路径的 fsync 延迟稳定性。
