MySQL 的 InnoDB 存储引擎使用 两阶段提交 来协调 redo log 和 binlog 的写入顺序，确保事务的一致性。具体过程如下：
-
准备阶段（Prepare Phase）：
- InnoDB 将事务修改写入 redo log，但此时 redo log 处于
prepare状态，表示事务的修改已经写入磁盘，但是还没有提交。 - 同时，MySQL 将事务的 binlog 写入 binlog buffer 中（还未刷到磁盘）。
- InnoDB 将事务修改写入 redo log，但此时 redo log 处于
-
提交阶段（Commit Phase）：
- 首先，MySQL 将 binlog buffer 中的内容刷入磁盘，写入 binlog 中。
- 然后，InnoDB 将 redo log 从
prepare状态切换为commit状态，标志事务最终提交完成。
这个过程确保了 binlog 和 redo log 的一致性。因为 binlog 用于主从复制、数据恢复等功能，所以需要确保事务在 binlog 中成功记录后，才能最终提交。
崩溃恢复时的决策机制
当 MySQL 服务器崩溃或断电时，事务可能正处于两阶段提交的中间状态，即 redo log 可能已经处于 prepare状态，但 binlog 还没有写入完成。此时，MySQL 会在恢复时根据以下原则来决定该事务是提交还是回滚：
-
如果找到对应的 binlog：
- MySQL 会检查 binlog 中是否有与 redo log 中相同的 XID（事务 ID）。
- 如果找到了相同的 XID，说明事务的 binlog 已经写入成功，事务可以安全地提交。因此，MySQL 会将 redo log 从
prepare状态变为commit状态，并提交该事务。
-
如果未找到对应的 binlog：
- 如果 binlog 中没有找到与 redo log 相同的 XID，则说明事务的 binlog 还未写入成功，这时 MySQL 会选择回滚该事务。MySQL 将删除
prepare状态的 redo log 并回滚事务。
- 如果 binlog 中没有找到与 redo log 相同的 XID，则说明事务的 binlog 还未写入成功，这时 MySQL 会选择回滚该事务。MySQL 将删除
这个机制确保了 MySQL 在崩溃恢复时能够根据事务日志的状态做出正确的决策，保持数据一致性。
为什么要检查 binlog？
- binlog 是 MySQL 中的逻辑日志，主要用于主从复制和数据恢复。如果 binlog 没有成功写入磁盘，可能会导致主从数据不一致。
- redo log 则是 InnoDB 的物理日志，用于崩溃恢复，记录了事务的物理更改。
- 通过将 redo log 和 binlog 结合使用，MySQL 能够在崩溃时恢复数据，同时保证数据复制的正确性。