MySQL 事务与 MVCC 深度剖析：从隔离级别到三大日志，一文打通并发与持久化

事务、MVCC 与三大日志

一条 UPDATE 语句，如何保证"要么全成功、要么全回滚"？并发事务之间为什么不会互相踩？
答案藏在三层结构里：事务隔离级别（语义层）→ MVCC 多版本控制（实现层）→ Redo/Undo/Binlog（持久层）。

一、事务与隔离级别

1.1 ACID

1.2 三大读问题

1.3 四种隔离级别

关键认知：MySQL 的 RR 在「快照读」下靠 MVCC 冻结快照消除幻读；在「当前读」下靠 Next-Key Lock 防幻读。锁机制见《03_锁机制与死锁防御》。

二、MVCC 多版本并发控制

MVCC 的核心思想：写数据时不覆盖旧数据（写入 undo log），读数据时按规则选择可见的旧版本。读写操作不同版本，互不干扰。

2.1 三大底层组件

组件一：隐藏字段（每行聚簇索引都有）

组件二：undo log 版本链 —— 数据的"时光机"

每次 UPDATE 前，先将旧值写入 undo log，新行的roll_pointer指向旧版本，形成从新到旧的单向链表。

B+Tree 物理行（只存最新版本） ┌───────────────────────────────────────┐ │ id=1, status=99, trx_id=10, │ │ roll_pointer ─────────────────────────┼───┐ └───────────────────────────────────────┘ │ ▼ undo log 版本1 ┌──────────────────────┐ │ status=0, trx_id=5, │ │ roll_pointer=NULL │ └──────────────────────┘

存储澄清：B+树叶子节点只存当前最新版本，历史版本链在 undo log 中。MySQL 8.0 默认存储在datadir下的undo_001、undo_002（独立.ibu文件）。

组件三：ReadView —— 判断"谁可见"的规则快照

ReadView 是纯内存结构，事务提交即销毁。包含 4 个字段：

ReadView 是全局的，不是行级的：从内存全局事务管理器复制整个实例的活跃事务列表。好处是跨表 JOIN 逻辑一致；代价是一个古老长查询会"挟持"所有表的历史版本（见保护伞效应）。

2.2 可见性判定算法（5 条规则，严格优先级）

对某版本行的trx_id = T：

① T == creator_trx_id ? → 可见 ✓（自己能看自己的修改） ② T < min_trx_id ? → 可见 ✓（生成前已提交） ③ T >= max_trx_id ? → 不可见 ✗（生成后才开启的新事务） ④ min_trx_id <= T < max_trx_id ? T 在 m_ids 列表中 ? → 不可见 ✗（生成时仍活跃，未提交） T 不在 m_ids 列表 ? → 可见 ✓（生成时已提交）

ASCII 数轴图解：

事务 ID 数轴 ──────────────────────────────────────────────────────► 0 ────── min_trx_id ─────── 活跃事务区间 ─────── max_trx_id ───► ∞ │ │ ↑ m_ids=[7,9,10] ↑ │ │ │ │ (trx_id 7,9,10 活跃) │ 可见区 │ 活跃区（查m_ids） │ 不可见区 (已提交) │ T=7 在m_ids→不可见 ✗ │ T=11,12→不可见 ✗ T=1,2,5 │ T=8 不在m_ids→可见 ✓ │ (未来事务) → 可见 ✓ │ T=9 在m_ids→不可见 ✗ │ │ T=10在m_ids→不可见 ✗ │

边界纠误：T == min_trx_id不可见（它在活跃列表里）；T == max_trx_id不可见（它是未来事务）。

2.3 ReadView 生成时机：RC vs RR 的本质区别

超高频考点：RR 下 ReadView 生成于第一条 SELECT，不是 BEGIN。
强制 BEGIN 时生成：START TRANSACTION WITH CONSISTENT SNAPSHOT;

RC 时间轴图解（两次查询 → 两个 ReadView）：

事务A (trx_id=7, RC) 事务B (trx_id=10) │ SELECT #1 │ │ → 生成 ReadView #1 │ │ m_ids=[8,10,12] (B 在活跃列表) │ │ → B+Tree trx_id=10 在 m_ids → 不可见 → 回溯旧版本 0 │ │ UPDATE status=99 / COMMIT │ │ (trx_id=10 从全局活跃列表移除) │ SELECT #2 │ │ → 生成 ReadView #2 ★ RC 每次都新 │ │ m_ids=[8,12] (B 已提交，不在列表) │ │ → B+Tree trx_id=10 → 8≤10<13，查 m_ids → 不在 → 可见 ✓ │ → 返回 status=99 └─ COMMIT ✅ 两次查询结果不同：0 → 99（不可重复读）

RR 时间轴图解（两次查询 → 同一个 ReadView）：

事务A (trx_id=7, RR) 事务B (trx_id=10) │ SELECT #1 │ │ → 生成 ReadView #1 ★ RR 只生成一次 │ │ m_ids=[8,10,12] (B 在活跃列表) │ │ → B+Tree trx_id=10 在 m_ids → 不可见 → 回溯旧版本 0 │ │ UPDATE status=99 / COMMIT │ │ (trx_id=10 从全局移除) │ SELECT #2 │ │ → 复用 ReadView #1 ★ 冻结不变！ │ │ m_ids=[8,10,12] (B 仍在列表里) │ │ → B+Tree trx_id=10 → 在 m_ids → 不可见 ✗ │ → 回溯旧版本 0 → 可见 ✓ └─ COMMIT ✅ 两次查询结果相同：0 → 0（可重复读 / 快照冻结）

关键：即使 B 真实已 COMMIT，ReadView #1 生成时把 B 记在了 m_ids 里，所以对 A 来说 B 的修改永远不可见。

2.4 快照读 vs 当前读

关键结论：UPDATE/DELETE内部先做当前读读到最新值，不管你显式SELECT查的是多少。

账户余额初始 1000，事务A 快照读两次，事务B 中间扣 100： 事务A（快照读） 事务B（当前写） ├─ SELECT balance → 1000 │ ├─ UPDATE SET balance=900 / COMMIT ├─ SELECT balance → 1000(RR) 或 900(RC) │ └─ UPDATE SET balance = balance - 50 → 内部当前读读到最新 900，减成 850 → 不会基于之前的快照读计算 ★ UPDATE/DELETE 内部的读取是当前读，不管你显式查的是多少

三、三大日志：Redo / Undo / Binlog

3.1 总览对比

核心哲学：日志记录"操作（Events）“，数据文件记录"状态（State）”。只要有一串完整的操作日志，就可以推导出任意时刻的状态。

3.2 WAL 机制：Redo Log 为什么快

• 刷数据页（脏页）：随机 I/O（磁盘寻道慢，毫秒级）
• 写 Redo Log：顺序 I/O（追加写，微秒级）

WAL（Write-Ahead Logging）：先写日志（顺序快），再异步刷脏页（随机慢）。宕机后通过 Redo Log 重放，恢复已提交但未刷盘的数据。

3.3 一条 UPDATE 的完整日志时序

UPDATEuserSETmoney=90WHEREid=1;

Undo Log 写入时机纠误：Undo Log 是执行 DML 的瞬间就写入的，不是提交时才写。原因：① 其他事务的 MVCC 快照读立刻需要读到旧值；② 用户随时可能 ROLLBACK，必须有 Undo 才能撤销。

四、内部 XA 两阶段提交

4.1 为什么需要

Redo Log（引擎层）和 Binlog（Server 层）是两个独立日志。如果只写其一就宕机：

• 只写 Redo，未写 Binlog→ 主库恢复有新数据，从库同步缺失 →主从不一致
• 只写 Binlog，未写 Redo→ 从库重放了数据，主库回滚了 →主从不一致

4.2 两阶段流程

4.3 崩溃恢复规则

核心规则：以Binlog 写成功作为事务最终提交的"决定性标志"。

五、分布式事务

5.1 为什么单机事务不够

单体事务只在一个数据库连接内生效。涉及多个 MySQL 实例（分库分表）或跨 Redis / MQ，需要分布式事务协调者（TC）介入。

5.2 外部 XA（强一致性，性能差）

XASTART'xid1';-- 代替 BEGINUPDATEuserSETmoney=money-10WHEREid=1;UPDATEuserSETmoney=money+10WHEREid=2;XAEND'xid1';XAPREPARE'xid1';-- 第一阶段：所有参与者 Prepare，锁不释放XACOMMIT'xid1';-- 第二阶段：全局提交（锁释放）

XA PREPARE后行锁一直持有，直到全局XA COMMIT才释放。强一致但性能极差，互联网大厂基本不用。

5.3 Seata AT 模式（最终一致性，高性能）

核心思想：一阶段直接提交本地事务，释放锁；二阶段如果失败，用undo_log表反向补偿。

Seata AT 一阶段（业务代码只需@GlobalTransactional）：

-- 业务代码：@GlobalTransactionalUPDATEuserSETmoney=money-10WHEREid=1;-- 框架自动执行（同一本地事务中）：-- 1. 查询 Before Image（修改前数据）-- 2. 执行业务 UPDATE-- 3. 查询 After Image（修改后数据）-- 4. INSERT INTO undo_log (xid, branch_id, before_image, after_image) VALUES (...)-- 5. COMMIT（释放本地锁）★ 与外部 XA 的核心差异

二阶段：

• 全局成功 → 框架异步删除undo_log记录
• 全局失败 → 框架读取before_image，生成反向 SQL 恢复数据

单体日志是分布式事务的"物理保险柜"：Seata 的undo_log写入磁盘时，必须依赖 Redo Log 保证不丢失、Binlog 保证同步到从库。如果 Redo Log 不起作用，Seata 刚写完undo_log就宕机，重启后记录丢失 → 无法恢复。

5.4 分布式事务角色

核心速查表

RC vs RR 对比

三大日志一句话

可见性判定口诀

自己可见 → 已提交的老事务可见 → 未来事务不可见 → 活跃列表里查旧账。