MySQL 事务的实现原理详解

原创于 2025-12-02 18:14:00 发布 · 637 阅读

22 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库 #事务 #隔离性

MySQL 事务的实现原理详解

重点围绕 InnoDB 存储引擎，因为真正支持事务的是 InnoDB。

一、事务与 ACID 简单回顾

事务（Transaction）：一组要么全部成功、要么全部失败的 SQL 操作，是数据库并发控制的基本单位。

ACID 四个特性：

原子性（Atomicity）
- 要么全部执行，要么全部回滚。
- 失败时，数据库能恢复到事务开始前的状态。
一致性（Consistency）
- 事务前后，数据库从一个“合法状态”到另一个“合法状态”。
- 约束（主键、唯一约束、外键等）不会被破坏。
隔离性（Isolation）
- 多个事务并发执行时，相互之间的可见性如何控制。
- 对应四种隔离级别：RU、RC、RR、Serializable。
持久性（Durability）
- 提交后的修改即使宕机也不会丢失。
- 靠的是各种日志和刷盘机制。

二、InnoDB 事务的大框架

InnoDB 为了实现 ACID，核心用到了这几样东西：

Redo Log（重做日志） —— 保证持久性
Undo Log（回滚日志） —— 保证原子性 + MVCC 的基础
锁（Lock）系统 —— 行级锁实现隔离性的一部分
MVCC（多版本并发控制） —— 实现 RC / RR 隔离级别下的“快照读”
两阶段提交（Redo Log + Binlog） —— 保证崩溃恢复 & 主从复制的一致性

整体可以理解为：

“写操作先记日志（WAL 思想），通过日志 + 版本控制 + 锁来维持 ACID。”

三、原子性：Undo Log 如何工作

原子性 = 要么全做，要么全不做。InnoDB 通过 Undo Log 实现“回滚能力”。

1. Undo Log 是什么

Undo Log 记录的是：如何把新数据恢复成旧数据。
例如：UPDATE t SET age = 18 WHERE id = 1;
- Undo 里会记录：原来的 age 是多少。

2. Undo Log 的作用

事务回滚
- 事务失败或主动 ROLLBACK 时，InnoDB 按 Undo Log 逆向操作，把数据恢复成修改前的版本。
MVCC 的版本链基础
- 每行记录除了当前值外，还通过 Undo Log 把历史版本串成一条“版本链”。
- 这样“快照读”就可以读到旧版本，做到“读到事务开始时的视图”。

3. Undo Log 的类型

Insert Undo Log：对 INSERT 操作产生。
- 事务未提交前，需要它来回滚“插入”。
- 提交后这类 Undo 其实可以被丢弃（因为没人再需要看到“插入之前”的“没有这条记录”的版本）。
Update Undo Log：包括 UPDATE、DELETE。
- 既用于回滚，也用于给其他事务提供历史版本（MVCC）。
- 提交后不能立刻删除，要等没有事务再需要这些旧版本。

四、持久性：Redo Log 与 WAL 思想

持久性 = 提交之后不能丢。

1. Redo Log 是什么

Redo 记录的是：对“数据页”的物理修改，类似于“操作步骤”。
比如：修改了哪一个表空间、哪一页、哪个偏移量、改成什么值。

2. 为什么需要 Redo Log

直接把页面写回磁盘成本很高：

随机写多、IO 慢；
如果宕机在一半，页面处于中间状态。

所以 InnoDB 采用 WAL（Write-Ahead Logging）：

先写 Redo Log（顺序写） 到日志文件/缓冲。
再异步把数据页刷回磁盘。

只要 Redo Log 写成功，就认为事务“持久化”了。

3. 提交时发生了什么

一个写事务大概流程：

修改内存中的 Buffer Pool 页（脏页）。
生成 Redo Log 写入 Redo Log Buffer。
事务 COMMIT 时，必须保证相关 Redo 至少刷新到磁盘（或者根据 innodb_flush_log_at_trx_commit 的策略）。
真正的数据页晚点刷也没关系，宕机时可以靠 Redo Log“重做”回来。

4. 崩溃恢复时 Redo 的作用

启动时：扫描 Redo Log，从最后一次一致性检查点开始重做，确保所有已经提交的事务都物理落盘。

五、隔离性：锁 + MVCC 的组合拳

隔离性主要通过两部分实现：

锁机制（Locking） —— 控制对“同一行或范围”的并发修改
MVCC（多版本并发控制） —— 让读操作尽量不用加锁，直接读“快照”

1. 锁的种类（InnoDB 行级锁）

常见锁：

记录锁（Record Lock）：锁住某一条记录。
间隙锁（Gap Lock）：锁住两个值之间的“间隙”，不锁已有记录。
Next-Key Lock：记录锁 + 间隙锁，锁住“某条记录以及它前面的间隙”，用于防止幻读。
意向锁（Intention Lock）：表级锁，用来快速判断“某个表上是否有人加过行锁”。

思路：在高并发下，通过尽可能细粒度的行锁 + 间隙锁控制写冲突。

2. MVCC 的基本结构

InnoDB 每行记录内部有几个隐藏字段：

trx_id：最近一次修改该行的事务 id。
roll_pointer：指向 Undo Log 中该行的前一个版本。

于是：

当前行 = 最新版本。
沿着 roll_pointer 可以找到历史版本。
不同事务按照自己的“快照规则”，去选择某个版本来读。

这样：

快照读（普通 SELECT）：不加锁，通过版本链读取旧数据版本。
当前读（SELECT … FOR UPDATE / UPDATE / DELETE）：要加锁，读的是当前最新版本。

六、四种隔离级别是如何实现的

MySQL 提供 4 种隔离级别：

读未提交（READ UNCOMMITTED，RU）
读已提交（READ COMMITTED，RC）
可重复读（REPEATABLE READ，RR）—— InnoDB 默认
串行化（SERIALIZABLE）

对应现象：脏读、不可重复读、幻读。

1. READ UNCOMMITTED

读操作可以看到“未提交事务”的修改。
实现上基本不使用 MVCC 快照，直接读最新版本。
问题多，一般不用。

2. READ COMMITTED

每条 SQL 开始时生成一个新的“快照”。
同一个事务内，不同的 SELECT 可能读到不同版本的数据（不可重复读）。
实现上：
- 通过 MVCC，按照当前语句执行时的活跃事务列表过滤版本。

3. REPEATABLE READ（InnoDB 默认）

在事务开始时生成一致性视图（快照）。
整个事务生命周期内，快照不变：
- 多次 SELECT 结果一样（可重复读）。
幻读问题：
- 对于快照读，通过 MVCC 的版本规则避免看到其他事务新插入的数据。
- 对于当前读（加锁的范围查询），通过 Next-Key Lock（记录锁 + 间隙锁）防止“幻影记录”插入。