当前位置：首页 > news >正文

Mysql 中的两阶段提交

news 2025/7/10 12:15:59

MySQL 中的“两阶段提交”（Two-Phase Commit，2PC）是用于分布式事务中的一种协议，目的是保证在多个数据库节点之间操作的一致性。虽然 MySQL 自身并不是分布式数据库，但在 使用 InnoDB 引擎和 binlog 的情况下，为了保证 InnoDB 引擎的事务和 binlog 写入的一致性，MySQL 内部也使用了一个简化的“两阶段提交”机制。

📌 1. 场景：InnoDB + Binlog 的一致性

在 MySQL 中，事务提交时需要：

把事务操作写入 InnoDB 的 redo log
把操作写入 binlog（用于主从复制、数据恢复）

要保证这两个步骤一致，MySQL 使用了 两阶段提交协议。

🧠 2. 两阶段提交的过程

✅ 第一阶段：准备阶段（Prepare Phase）

InnoDB 引擎将事务的修改写入 redo log，并写入 prepare 状态（此时 redo log 并未提交）。
如果写入 redo log 成功，则继续。

✅ 第二阶段：提交阶段（Commit Phase）

MySQL Server 层将事务写入 binlog。
如果写入成功：
- 通知 InnoDB 提交 redo log（即将 redo log 状态从 prepare 改为 commit）。
如果写入 binlog 失败：
- 则回滚事务，并让 InnoDB 回滚 redo log。

✅ 3. 为什么需要两阶段提交？

因为：

InnoDB 的 redo log 和 binlog 是 两个独立的系统。
必须保证 两者一致，否则在 crash 恢复或者主从复制时可能出现数据不一致。

举个例子，如果：

redo log 已经提交（物理上持久化）
但 binlog 写入失败（主从复制数据就丢了）

这就会导致数据不一致。

解释

“redo log 已经提交（物理上持久化），但 binlog 写入失败”
意思是：

InnoDB 的事务操作已经写入了 redo log 并提交（事务在本地已经真正生效了）。
但是 binlog（用于主从复制和 crash 恢复）没有成功写入磁盘或写失败。

⚠️ 会出现什么后果？

主库上事务已经生效（数据已经更新）
binlog 没有记录这个操作
从库在复制时不会收到这个事务的数据
➜ 导致主库和从库的数据出现不一致❗️

⛓️ 举个简单例子：

在主库执行了这个 SQL：

UPDATE accounts SET balance = balance - 100 WHERE id = 1;

执行过程：

InnoDB 引擎生成了 redo log，并持久化（prepare + commit）
数据 已经写入磁盘并对用户可见
接下来要写 binlog
突然磁盘坏了、网络抖动、或者某些内部故障导致 binlog 写入失败
MySQL 没能把这个操作记录到 binlog

🔥 结果：

主库余额真的变少了（InnoDB 的数据生效）
从库完全不知道这件事（因为没有 binlog 传过去）
➜ 主从数据不一致，坏了！

为了避免这种情况，MySQL 使用了两阶段提交来保证：

要么 redo log 和 binlog 都写成功并提交
要么 都不提交，回滚掉

这样就能保证主库和从库保持数据一致性。

🧠 可以这样理解：

步骤	redo log	binlog	最终事务状态
正常提交	✅	✅	提交
redo 成功，但 binlog 失败	✅	❌	⚠️ 数据不一致（必须避免）
redo 失败	❌	❌	回滚
binlog 成功，redo 未 prepare	❌	✅	回滚