开启binlog后不启用两阶段提交必然导致数据不一致：redo log与binlog脱节会使主库恢复状态错乱，造成主从反向或单向不一致；两阶段提交是强制协议，prepare→binlog fsync→commit顺序不可逆，禁用innodb_support_xa或跳过prepare将退化为单阶段提交，引发备份卡顿、gtid异常等线上故障。
开启 binlog 后不启用两阶段提交，MySQL 崩溃恢复或主从同步时必然出现数据不一致——这不是概率问题，而是确定性错误。
崩溃恢复时 redo log 和 binlog 脱节会直接导致主库状态错乱
MySQL 重启后靠 redo log 恢复已提交事务，但回放 binlog 是另一套逻辑。如果两者没对齐：
- redo log 已刷盘、binlog 写失败 → 主库恢复出该事务，但从库没收到，主从差一条
- binlog 已刷盘、redo log 还卡在 buffer 或 crash 前未标记 commit → 主库重启后丢掉该事务，但从库重放 binlog 执行了它，主从反向不一致
这两种情况在 innodb_flush_log_at_trx_commit=0 或 sync_binlog=0 下极易触发，且无法靠人工干预修复。
两阶段提交不是“可选优化”，而是原子性协同的强制协议
prepare 阶段和 commit 阶段不是为了性能，而是为建立跨层依赖关系：
-
prepare必须落盘（fsync），且仅由 InnoDB 完成；此时事务不可见、锁未释放、MVCC 不推进 - Server 层只有收到 prepare 成功响应，才开始写 binlog 并
fsync；任一环节失败，整个事务 rollback -
commit阶段只是 InnoDB 将已 prepare 的事务打上 commit 标记——它不写新日志，只改状态
这个顺序不可逆：prepare → binlog write+fsync → commit。颠倒或跳过 prepare，XA RECOVER 就无法识别悬挂事务。
真正容易被忽略的是三个运行时副作用
它们不报错，但会在高并发或长事务场景下悄悄破坏一致性保障：
-
innodb_support_xa=OFF会彻底禁用 prepare 阶段，退化为单阶段提交——5.7.9+ 默认 ON，但某些运维脚本或容器镜像可能显式关闭它 - 长时间未完成的 prepared 事务（比如应用端卡在 commit 前）会阻塞
mysqldump --single-transaction的快照点推进，导致备份卡住甚至超时 - GTID 模式下，prepared 事务的
XID已被分配但未提交，SHOW PROCESSLIST显示为Commit状态而非Locked，排查锁等待时极易漏掉
这些不是理论边界 case，而是线上慢查询、备份失败、主从延迟突增的真实诱因——尤其当 binlog_group_commit_sync_delay 被调大后，prepare 到 commit 的窗口期变宽，出问题的概率指数上升。
