XA内部事务两阶段提交
核心机制：两阶段提交的 5 大物理步骤
为了压榨磁盘性能，MySQL 将日志的“写入文件系统缓存（write）”与“物理持久化（fsync）”进行了精密拆解。以下是一个事务完整提交的物理历程：
1. redo log prepare: write
- 物理动作：每个事务各自将 redo log 从
redo log buffer写入操作系统的Page Cache。 - 状态：此时日志已离开 MySQL 进程，但仍处于系统内存中，未真正落地 。
2. binlog: write
- 物理动作：每个事务将自己的 binlog 从线程私有的
binlog cache写入系统的Page Cache。 - 目的：为接下来的“组提交”积蓄力量。
3. redo log prepare: fsync <-- 【Redo Log 组提交发生在这里】
- 物理动作：MySQL 调用操作系统的
fsync指令，将Page Cache中处于prepare状态的 redo log 集中刷入磁盘 。 - 黑科技：组提交（Group Commit）：由于多个并发事务生成的 LSN（日志序列号）是连续的，第一个到达的事务会成为“组长”，一次磁盘 IO 就能带走整组事务的日志 。这意味着并发越高，IO 效率越高 。
4. binlog: fsync <-- 【Binlog 组提交发生在这里】
- 物理动作：将
Page Cache中的 binlog 数据集体持久化到磁盘 。 - 优化方案：通过设置延迟参数（如
binlog_group_commit_sync_delay），可以人为拉长等待时间，让更多事务加入这一步的“刷盘班车”，进一步降低 IOPS 。
5. redo log commit: write
- 物理动作：在
Page Cache中将事务状态从prepare标记为commit。 - 为何不需要 fsync？：这是一个精妙的性能优化。由于前两步已经保证了 redo log 的
prepare记录和完整的binlog都在磁盘上，即使系统此时宕机，重启后 MySQL 依然能根据这两者恢复事务 。因此，最后的commit标记只需写到内存缓存即可，无需再次昂贵的刷盘操作 。
异常崩溃与自救指南
为了方便理解，我们假设在每一个物理步骤执行完的瞬间，数据库服务器突然断电宕机。
步骤 1 & 2：写入 Page Cache 阶段（未刷盘）
- 物理状态：日志仅存在于操作系统的内存缓存（Page Cache）中 。
- 崩溃后果：由于数据没有落盘，断电后这部分内存数据全部丢失 。
- 重启恢复：MySQL 重启后，由于磁盘上完全没有该事务的痕迹，该事务就像从未发生过一样。由于此时尚未给客户端返回“提交成功”，这种丢失是符合一致性的 。
步骤 3：redo log prepare: fsync完成
- 物理状态：redo log 已持久化到磁盘，状态为
prepare；但 binlog 还在内存或甚至还没写完 。 - 崩溃后果：磁盘上有
prepare记录，但没有对应的 binlog。 - 重启恢复：回滚（Rollback）。
- 原因：binlog 是主备复制的唯一依据。如果此时判定事务成功，主库有数据但备库没有（因为 binlog 丢了），会造成严重的主备不一致。
步骤 4：binlog: fsync完成
- 物理状态：redo log 处于
prepare状态，binlog 已完整写入磁盘 。 - 崩溃后果：磁盘上同时具备了
prepare记录和完整的 binlog，但 redo log 里的commit标记还没写 。 - 重启恢复：自动提交（Commit）。
- 原因：既然 binlog 已经安全落盘，意味着该事务一定会同步到从库。为了保证主从一致，主库在重启后会扫描发现“
prepare+完整 binlog”的组合，从而自动将该事务补全为提交状态 。
步骤 5：redo log commit: write完成
- 物理状态：事务在逻辑上已经彻底完成，但在物理上，redo log 里的
commit标记可能还在 Page Cache 里没刷到磁盘 。 - 崩溃后果：虽然磁盘上可能还没看到
commit标记，但状态与步骤 4 完全一致。 - 重启恢复：自动提交（Commit）。
- 原理：同步骤 4。只要
prepare记录和 binlog 都在，即使commit标记没刷盘，MySQL 也能确信这个事务是安全的，从而完成恢复 。