两阶段提交

两阶段提交的目的

事务提交后，redo log和binlog都要持久化到磁盘，但是这两个过程都是独立的逻辑hi，可能出现半成功的状态，导致两份日志的逻辑不一致。

两阶段提交是为了解决redo log(InnoDB事务日志)与binlog(MySQL归档日志)的数据一致性，确保：

事务提交后，两者要么都持久化要么都不持久化，避免因日志不全导致主从复制或数据恢复时出现不一致。

完整流程

阶段1:Prepare(准备阶段)

1.写redo log:事务执行修改操作，生成redo log，并写入日志文件，标记为Prepare状态(此时redo log已刷盘)。

2.内存记录状态:InnoDB存储引擎记录事务状态为Prepared,但不提交事务(数据未最终落盘生效)。

阶段2：commit(提交阶段)

1.写binlog：将事务操作写入binlog，并刷盘持久化(关键binlog必须成功刷盘，否则回滚)。

2.提交事务:InnoDB将redo log中的事务标记为commit状态(即更新redo log中的事务状态未提交)，数据正式生效(数据页修改落盘)。

异常情况

binlog刷盘失败

场景描述

事务完成prepare阶段(redo log已刷盘)，但commit阶段写入binlog时失败。

处理逻辑

1.立即回滚内存数据

        用undo log撤销内存中数据页的修改(恢复到事务前的旧值)，确保用户看不到未提交的脏数据。

2.redo log的处理

        物理保留但逻辑失效:磁盘中的redo log文件(prepare状态)不删除，但标记未"无效"(之后会被新日志覆盖)

        崩溃恢复时校验:

        若数据库崩溃后重启，InnoDB扫描redo log时，发现prepare状态的事务，会检查对应的binlog是否存在: 

        若binlog不存在(未刷盘成功)，则丢弃该redo log的应用(不执行数据恢复，相当于事务未提交)。

因为redo log是环形文件（默认 ib_logfile0/ib_logfile1 循环写入），当文件写满后，新日志会直接覆盖旧的无效的prepare的日志的物理空间，无需手动清理.

redo log刷盘失败

场景描述

事务在prepare阶段，因磁盘故障、IO错误等原因，导致redo log未成功刷盘。

处理逻辑

事务会直接回滚：由于redo log未刷盘，InnoDB存储引擎无法通过日志恢复事务，因此直接放弃该事务：

        内存中的数据页修改通过undo log回滚(恢复旧值)

        事务标记未中止，不产生任何持久化的影响

binlog不会写入：因为prepare阶段未完成，不会进入commit阶段，binlog自然不会记录该事务。

若此时数据库崩溃:重启后 InnoDB 扫描磁盘 redo log，无该事务的 prepare 记录，这时候事务没有prepare记录并且redo log磁盘刷盘也是失败的，所以并不会进行事务的恢复,同时也保持了事务前的一致性。