mysql通过两阶段提交协同写入：先在redo log中写入prepared状态并刷盘，再写入binlog并刷盘，最后将redo log置为commit状态；崩溃时依据xid比对redo log与binlog决定提交或回滚，确保数据一致性。
UPDATE语句提交时，redo log 和 binlog 怎么协同写入？
因为 UPDATE 是事务性操作，MySQL 必须保证崩溃后数据可恢复、主从复制不丢数据、备份能还原到一致状态。这要求 redo log（InnoDB 层）和 binlog（Server 层）两个日志必须“同进退”——要么都成功，要么都不算数。但它们物理上独立、归属不同模块，天然存在写入时间差。两阶段提交就是为堵住这个时间差带来的逻辑裂缝。
崩溃发生在 prepare 和 commit 之间，会怎样？
这是最常被忽略的临界点。比如 UPDATE accounts SET balance = balance - 100 WHERE id = 1 执行完，redo log 已 fsync 到磁盘并标记为 PREPARED，但 binlog 还没写完就 crash —— 此时 MySQL 启动时会做如下判断：
- 扫描
redo log中所有PREPARED事务 - 对每个事务，去
binlog文件里查对应 XID（事务唯一标识）是否存在 - 如果存在 → 补
COMMIT，该事务生效 - 如果不存在 → 视为未提交，直接回滚
这个机制让崩溃恢复有了明确依据，而不是靠运气猜哪个日志“更可信”。
sync_binlog 和 innodb_flush_log_at_trx_commit 怎么配才不翻车？
这两个参数直接决定两阶段提交的可靠性边界：
-
sync_binlog = 1：每次事务提交都调用fsync()刷binlog，确保 binlog 不丢，但性能略低 -
innodb_flush_log_at_trx_commit = 1：每次事务提交都刷redo log，保证崩溃不丢已提交事务 - 若两者都设为
1，才能真正实现“强一致性”。设成0或2会导致某一方日志可能丢失，两阶段提交就形同虚设
特别注意：sync_binlog = 0 表示依赖操作系统缓存，MySQL 崩溃时 binlog 可能全丢；而 innodb_flush_log_at_trx_commit = 2 只写 OS 缓存，机器断电时 redo log 也可能丢失。
为什么不能只靠 redo log 或只靠 binlog？
单靠任一者都会在特定场景下失效：
- 只靠
redo log：能恢复主库本地状态，但无法支撑主从复制或基于时间点的备份恢复（binlog是唯一支持 PITR 的日志） - 只靠
binlog：没有事务原子性保障，也无法处理崩溃时未刷盘的脏页，InnoDB 自己都恢复不了数据 - 两阶段提交不是锦上添花，而是把两个“半成品日志”焊成一个逻辑整体的必要工序
真正容易被忽略的，是 PREPARED 状态本身——它既不是提交也不是回滚，而是一种“悬停态”，专门留给崩溃恢复时做最终仲裁。这个状态的存在，才是两阶段提交区别于简单顺序写日志的本质。
