MySQL一致性需二阶段提交+innodb_flush_log_at_trx_commit=1+sync_binlog=1；否则宕机可能丢事务、主从分裂；Redo Log alone无法保证因Binlog与Redo Log需原子性协同。
MySQL 能保证一致性，前提是开启了二阶段提交（2PC），且 innodb_flush_log_at_trx_commit = 1、sync_binlog = 1 同时生效。否则宕机后可能丢事务、读到不一致状态，甚至主从数据分裂。
为什么单靠 Redo Log 不够
Redo Log 只管 InnoDB 引擎层的物理页修改，它能保证崩溃后已提交事务不丢失——但前提是：这个“已提交”是数据库自己认定的。如果事务在写完 Redo Log 后、还没来得及写 Binlog 就宕机，MySQL 启动时会认为该事务未完成，直接丢弃；而如果 Binlog 已写入、Redo Log 没刷盘，备库可能重放了这条日志，主库却没应用，造成主从不一致。
所以必须让两个日志达成一致：要么都成功，要么都失败。这就是二阶段提交的必要性。
- Redo Log 的 prepare 阶段：事务进入准备提交状态，Redo Log 写入并刷盘，但不标记为 commit
- Binlog 写入阶段：MySQL Server 层将事务的变更写入 Binlog 并刷盘（依赖
sync_binlog = 1） - Redo Log 的 commit 阶段：Server 层通知 InnoDB 提交，Redo Log 补上 commit 标记并刷盘
二阶段提交失败时 MySQL 怎么恢复
MySQL 启动时会扫描 Redo Log，检查其中处于 prepare 状态但没有 commit 标记的事务：
- 若对应 XID 在 Binlog 中存在 → 认定事务已成功，补全 Redo Log 的 commit 标记，完成提交
- 若 Binlog 中找不到该 XID → 认定事务未真正提交，直接回滚（用 Undo Log 撤销）
这个逻辑隐含一个前提：binlog_format = ROW 且 binlog_checksum = CRC32（推荐），否则 Binlog 解析可能出错，恢复判断失效。
常见配置踩坑点
以下组合会导致宕机后无法保证一致性：
-
innodb_flush_log_at_trx_commit = 0或2：Redo Log 可能未落盘，prepare 状态丢失，恢复时无法判断，事务直接消失 -
sync_binlog = 0：Binlog 缓存在内存，宕机即丢，导致主从不一致或恢复时误判为“未提交” - 使用
STATEMENT格式的 Binlog：某些函数（如NOW()、UUID()）在主从执行结果不同，即使 2PC 成功也无法保证语义一致 - 事务中混用 MyISAM 表：MyISAM 不支持事务，也不写 Redo Log，其修改无法参与 2PC，必然破坏原子性
如何验证你的实例是否真正启用 2PC
执行以下命令确认关键参数是否就位：
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit'; SHOW VARIABLES LIKE 'sync_binlog'; SHOW VARIABLES LIKE 'binlog_format';
再查一下当前是否有 prepare 状态事务残留（正常应为空）：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'PREPARED';
如果有非空结果，说明有事务卡在 prepare 阶段未完成——这通常是崩溃前的征兆，或是 binlog 写入失败被阻塞，需立刻排查磁盘空间、权限或 I/O 延迟。
真正难处理的不是宕机本身，而是那些看似“成功提交”、实则只写了一半日志的边界情况。参数配对、格式统一、引擎一致，三者缺一不可。
