MySQL Commit如何协调两阶段提交

先说结论：MySQL的COMMIT并不是一次性完成的动作，而是InnoDB和Server层之间的一场“双人交接”。你看到的“提交成功”，其实是协调者——也就是InnoDB事务管理模块，确认了redo log和binlog都已经按顺序落盘、并且状态一致后的结果。整个过程分成两阶段，这也是数据库领域经典的“两阶段提交”协议，即MySQL两阶段提交机制的核心。

prepare阶段：先让redo log进入可恢复状态

执行COMMIT之后，InnoDB会立刻进入prepare阶段。具体来说：

• redo log先写入缓冲区，然后调用fsync刷盘——这个行为受innodb_flush_log_at_trx_commit=1控制。刷盘时，redo log的状态会被标记为PREPARE，同时写入一个事务唯一标识：XID。
• 注意，此时数据还没有对外可见，锁也没有释放，undo log更不会清理。换句话说，事务还在“半空中”。
• 关键点在于：如果这一刻系统崩溃，InnoDB重启后会扫描redo log，发现存在PREPARE状态的事务，但它不会直接提交——它要等binlog的“判决”。

commit阶段：binlog成为最终裁决者

Server层收到InnoDB的prepare成功反馈后，才开始写binlog。流程是这样的：

• binlog追加写入文件，并调用fsync（受sync_binlog=1控制）。这条binlog记录必须关联同一个XID。
• 如果binlog写失败——比如磁盘满了或者权限错误——Server层会通知InnoDB执行rollback，这个事务就彻底作废了。
• 如果binlog写成功，Server层就会向InnoDB发送commit指令。InnoDB收到后，会把redo log中对应XID的记录状态更新为COMMIT——注意，这一步不强制刷盘，只需要写入OS page cache。
• 然后，释放锁、清理undo log，事务才算真正结束。

崩溃恢复时，MySQL怎么“读心”？

MySQL重启时并不会“猜测”某个事务的状态，而是严格比对两个日志中的XID：

• 如果redo log里有XID标记为PREPARE，但binlog里查不到该XID——说明binlog写失败了，系统会认定这个事务需要回滚，自动执行rollback。
• 如果binlog里有该XID，但redo log中无对应PREPARE记录——这种情况理论上是不会发生的，因为binlog写入前必须经过prepare阶段。如果出现，说明流程被绕过了（比如禁用了innodb_support_xa），这将直接导致主从不一致。
• 只有两者都存在并且匹配，系统才会完成最终提交。这就是为什么binlog在恢复过程中充当“裁判”角色。

容易被忽略的配置陷阱

两阶段提交能不能真正起作用，高度依赖两个参数的实际值。这里有几个常见的配置陷阱：

• innodb_flush_log_at_trx_commit=0或2：prepare阶段的redo log可能没有刷盘，崩溃后连PREPARE状态都丢失了，但binlog却已经存在。这种情况会导致主从不一致。
• sync_binlog=0：binlog只写入文件系统缓存，崩溃后丢失。InnoDB会因找不到XID而回滚事务，但业务端可能已经收到了“提交成功”的响应。
• innodb_support_xa=OFF（MySQL 5.7.7之后默认是ON）：如果禁用了XA协议支持，会跳过prepare阶段，直接退化为单阶段提交，完全破坏2PC机制。

说白了，真正起作用的不是COMMIT这个语句本身，而是背后那套靠XID对齐、靠fsync顺序、靠崩溃后交叉校验来维持的协作逻辑。一旦任何一个环节脱离了这个链条，一致性就不再有任何保障。