MySQL崩溃恢复不能只重放redo log，因为需通过XID交叉验证binlog与redo log一致性：扫描redo log中PREPARED事务的XID，再比对binlog末尾XID_EVENT中的XID，二者同时存在才提交，否则回滚，避免主从不一致。
MySQL 通过内部两阶段提交（Internal XA）强制 binlog 和 redo log 的写入具备原子性，崩溃后靠 XID 匹配决定事务最终状态——不是简单重放 redo log，而是交叉验证两者是否同时存在。
崩溃恢复时为什么不能只重放 redo log？
因为 redo log 是 InnoDB 引擎层日志，binlog 是 Server 层日志，InnoDB 不感知 binlog 是否写成功。如果只按 redo log 恢复：
- 事务在
redo log中处于PREPARED状态，但binlog写失败 → 主库恢复后有数据，从库无该事务 → 主从永久不一致 - 事务已写入
binlog，但redo log提交阶段 crash → 从库能复制，主库却没真正提交 → 数据逻辑错误
所以恢复必须查 XID：InnoDB 扫描所有 PREPARED 事务的 XID，再在 binlog 文件末尾提取所有 XID_EVENT 中的 XID，逐个比对。
两阶段提交中 prepare 和 commit 的实际落盘行为
prepare 阶段由 InnoDB 控制，commit 阶段由 Server 层协调，二者刷盘策略相互影响：
-
innodb_flush_log_at_trx_commit=1时，prepare阶段就调用fsync()将redo log刷盘；否则可能只写入redo log buffer -
sync_binlog=1时，Server 层在commit阶段才把binlog刷盘；若设为 0 或 N，则binlog可能延迟落盘，导致XID在binlog中不可见 - 即使
innodb_flush_log_at_trx_commit=2，只要sync_binlog=1，仍能保证一致性——因为prepare成功后，binlog必须落盘，Server 层才会通知 InnoDBcommit
常见一致性破坏场景及参数组合风险
以下配置组合会直接破坏 binlog/redo log 一致性保障能力：
-
sync_binlog=0+innodb_flush_log_at_trx_commit=0：事务提交后，两个日志都未刷盘，MySQL 进程 crash 会导致事务完全丢失，且无任何恢复依据 -
sync_binlog=1但innodb_flush_log_at_trx_commit=0：binlog已落盘，redo log还在内存或 OS 缓存中 → MySQL crash 后重启，binlog有记录、redo log无对应PREPARED事务 → 恢复流程无法识别该事务，主从数据错位 - 手动关闭
innodb_support_xa=OFF（MySQL 5.7+ 默认 ON）：禁用 Internal XA，两阶段提交退化为单点提交，binlog和redo log完全解耦
真正关键的不是“有没有两阶段提交”，而是 prepare 和 commit 对应的日志是否都落到持久化介质上——中间任意一环掉链子，XID 就无法匹配，崩溃恢复就失去判断依据。
