京东面试官揪着问的 InnoDB如何用MVCC和Next-Key Lock实现RR隔离？看完顿悟！

本文将不仅详细解释每种隔离级别的定义和现象，更会深入 InnoDB 存储引擎层，探讨其背后的多版本并发控制（MVCC）和锁机制是如何协同工作来实现这些隔离级别的。

什么是事务 ACID

在深入隔离级别之前，我们必须先统一共识：什么是事务？为什么需要它？

事务是数据库操作的一个最小逻辑工作单元，其内的所有操作要么全部成功，要么全部失败。一个经典的例子就是银行转账：从 A 账户扣款和向 B 账户加款，这两个操作必须作为一个整体，不能分割。

为了确保事务的可靠性和数据的一致性，数据库系统必须满足 ACID 属性：

原子性 (Atomicity)： 事务是一个不可分割的整体，就像原子一样。它要么全部完成，要么全部不完成，不存在中间状态。InnoDB 通过Undo Log来实现原子性。如果事务失败，Undo Log 会将已经修改的数据恢复到事务开始前的状态。一致性 (Consistency) ： 事务的执行必须使数据库从一个一致性状态变换到另一个一致性状态。一致性是应用的最终追求，原子性、隔离性和持久性都是为实现一致性而存在的。例如，转账前后，两个账户的总金额必须保持不变。隔离性 (Isolation) ： 这是我们今天讨论的重点。多个并发事务对数据进行修改和访问时，数据库系统必须提供一种机制来防止事务间的相互干扰，使得各个事务感觉不到其他事务在并发执行。隔离级别就是用来定义这种“隔离”的严格程度的。持久性 (Durability) ： 一旦事务提交，其对数据的修改就是永久性的，即使系统发生故障也不会丢失。InnoDB 通过Redo Log来实现持久性。修改数据时，首先会写入 Redo Log，再在合适的时间点刷写到磁盘数据文件。即使系统崩溃，也能通过 Redo Log 恢复已提交的事务。

隔离性的挑战： 完全隔离（串行化执行）固然安全，但会极大限制数据库的并发处理能力，导致性能急剧下降。因此，数据库系统提供了多种隔离级别，让开发者可以在性能和数据一致性之间进行权衡。

并发事务并发的三个问题

在介绍隔离级别之前，我们必须先了解如果不进行任何隔离控制，并发事务会引发哪些问题。隔离级别本质上就是为了解决这些问题而存在的。

脏读 (Dirty Read)

一个事务读到了另一个未提交事务修改的数据。如果另一个事务中途回滚，那么第一个事务读到的数据就是“脏”的、无效的。

示例：

事务 A 将账户余额从 100 元修改为 200 元（但未提交）。此时事务 B 读取余额，得到了 200 元这个结果。事务 A 因某种原因回滚，余额恢复为 100 元。事务 B 之后的操作都是基于错误的“200 元”余额进行的。

图片

不可重复读 (Non-Repeatable Read)

一个事务内，两次读取同一个数据项，得到了不同的结果。重点在于另一个已提交事务对数据进行了修改（UPDATE）。

示例：

事务 A 第一次读取账户余额为 100 元。此时事务 B 提交了修改，将余额更新为 150 元。事务 A 再次读取余额，得到了 150 元。两次读取结果不一致。

幻读 (Phantom Read)

一个事务内，两次执行同一个查询，返回的结果集行数不同。重点在于另一个已提交事务对数据进行了增删（INSERT/DELETE），像产生了幻觉一样。

示例：

事务 A 第一次查询年龄小于 30 岁的员工，返回了 10 条记录。此时事务 B 提交了一个新操作，插入了一名 25 岁的员工记录。事务 A 再次执行相同的查询，返回了 11 条记录。

不可重复读 vs 幻读：

不可重复读针对的是某一行数据的值被修改（UPDATE）。幻读针对的是结果集的行数发生变化（INSERT/DELETE）。

SQL 标准下的四种事务隔离级别

为了解决上述问题，SQL 标准定义了四种隔离级别，严格程度从低到高。级别越高，能解决的问题越多，但并发性能通常越低。

隔离级别

脏读

不可重复读

幻读

读未提交 (Read Uncommitted)

❌ 可能

❌ 可能

❌ 可能

读已提交 (Read Committed)

✅ 避免

❌ 可能

❌ 可能

可重复读 (Repeatable Read)

✅ 避免

✅ 避免

❌ 可能

串行化 (Serializable)

✅ 避免

✅ 避免

✅ 避免

注意： 在 MySQL 的 InnoDB 引擎中，通过 Next-Key Locking 技术，在可重复读（Repeatable Read） 隔离级别下就已经可以避免绝大部分的幻读现象。这是 MySQL 对标准隔离级别的增强，也是其默认使用该级别的重要原因。

深入 InnoDB 的 MVCC 与锁机制

MySQL 的服务层负责事务管理，确保在执行一系列操作时，满足原子性、一致性、隔离性和持久性这四个特性。事务管理涉及的主要功能包括：

事务隔离级别：MySQL 支持四个事务隔离级别：读未提交、读已提交、可重复读和串行化。这些隔离级别分别定义了事务间数据访问的隔离程度，用于防止脏读、不可重复读和幻读。锁管理：在事务过程中，可能需要对数据加锁，以确保数据的一致性。MySQL 支持的锁类型包括共享锁、排它锁、意向锁、行锁、表锁等。Undo 日志：服务层通过 Undo 日志实现了事务回滚操作，当事务执行中途出现异常或用户发出回滚请求时，可以通过 Undo 日志回滚数据到事务开始前的状态。Redo 日志：为了保证事务的持久性。

要理解不同隔离级别是如何实现的，我们必须揭开 InnoDB 的两大核心法宝：多版本并发控制 (MVCC) 和 锁 (Locking) 。

MVCC： snapshot vs current

MVCC 的核心思想是为每一行数据维护多个版本（通常是两个），通过某个时间点的“快照”（Snapshot）来读取数据，从而避免加锁带来的性能损耗，实现非阻塞的读操作。

InnoDB 为每行记录隐式地添加了三个字段：

DB_TRX_ID（6 字节）： 最近一次修改该行数据的事务 ID。DB_ROLL_PTR（7 字节）： 回滚指针，指向该行数据在 Undo Log 中的上一个历史版本。DB_ROW_ID（6 字节）： 行标识（隐藏的主键，如果表没有主键）。

关键概念：ReadView在 MVCC 中，事务在执行快照读（普通的SELECT语句）时会生成一个一致性视图，即ReadView。ReadView 是 InnoDB 实现 MVCC 的核心数据结构，它包含：

m_ids：生成 ReadView 时活跃的事务 ID 列表min_trx_id：活跃事务中的最小 IDmax_trx_id：下一个将被分配的事务 IDcreator_trx_id：创建该 ReadView 的事务 ID

通过 ReadView，InnoDB 可以判断某个数据版本对当前事务是否可见。

数据可见性规则： 当一行数据被访问时，InnoDB 会遍历其版本链（通过DB_ROLL_PTR指针），并应用以下规则来判断哪个版本对当前事务是可见的：

如果数据版本的trx_id < min_trx_id，说明该版本在 ReadView 创建前已提交，可见。如果数据版本的trx_id >= max_trx_id，说明该版本在 ReadView 创建后才开启，不可见。如果min_trx_id <= trx_id < max_trx_id，则需判断trx_id是否在m_ids中：

如果在，说明创建 ReadView 时该事务仍活跃，其修改未提交，不可见。

如果不在，说明创建 ReadView 时该事务已提交，可见。

如果当前记录的事务 ID 等于creator_trx_id，说明是本事务自己修改的，可见。

锁机制

MVCC 主要解决了“读”的并发问题，而“写”（INSERT, UPDATE, DELETE）依然需要通过加锁来保证数据正确性。

共享锁 (S Lock)： 允许事务读一行数据。其他事务可以同时获取共享锁，但不能获取排他锁。排他锁 (X Lock)： 允许事务更新或删除一行数据。其他事务无法获取该行的任何锁。

此外，InnoDB 还引入了意向锁（Intention Locks），是一种表级锁，用来表示事务稍后会对表中的某一行加上哪种类型的锁（共享或排他）。目的是为了更高效地判断表级锁冲突。

图片

各级别详解与 InnoDB 实现剖析

现在我们结合 MVCC 和锁，来看看每个隔离级别在 InnoDB 中是如何具体工作的。

1. 读未提交 (Read Uncommitted)

在读未提交级别下，InnoDB 几乎不进行隔离控制，事务可以直接读取数据页上的最新值，无论其他事务是否已提交。

实现原理： 几乎不加读锁。一个事务可以直接看到其他未提交事务修改后的最新值。它直接读取数据页的最新版本，完全无视 MVCC 和 Undo Log 版本链。问题： 所有并发问题都无法避免。应用场景： 几乎没有使用场景，除非你完全不在乎数据一致性，且追求极致的并发（但性能提升微乎其微，风险极大）。

实现特点：

不使用 MVCC 快照读操作不加锁（除非使用 FOR UPDATE 等加锁读）性能最高但数据一致性最差

2. 读已提交 (Read Committed, RC)

在读已提交级别下，InnoDB 使用 MVCC 确保事务只能读取已提交的数据。

如何解决脏读： 一个事务只能读到其他事务已经提交的修改。InnoDB 实现：

读操作 (SELECT)： 每次执行快照读时都会生成一个新的 ReadView。这意味着每次读都能看到最新提交的数据。

写操作 (UPDATE/DELETE)： 使用行级排他锁，并且语句执行时会扫描最新的数据。它还需要记录 Undo Log，以便在事务回滚时使用。

存在的问题： 因为每次 SELECT 都生成新 ReadView，所以同一事务内两次读取可能看到其他事务提交的修改，导致不可重复读和幻读。

实现特点：

每个语句开始时创建新的 ReadView使用语句级快照而非事务级快照通过 MVCC 避免脏读

RC 级别下的 MVCC 示例： 假设初始值 balance = 100。

时间序列

事务 A (trx_id=10)

事务 B (trx_id=20)

事务 A 的 ReadView 与读取结果

T1

BEGIN;

BEGIN;

-

T2

UPDATE account SET balance = 200 WHERE id=1;

-

T3

SELECT balance FROM account WHERE id=1;

 (生成 ReadView1: m_ids=[10,20], min=10, max=21) 检查数据行 trx_id=10，它在 m_ids 中且 ≠ 自己，不可见。沿 Undo Log 找到上一个版本(trx_id=可能为 null)，读取到 100。

T4

COMMIT;

-

T5

SELECT balance FROM account WHERE id=1;

 (生成新的ReadView2: m_ids=[20], min=20, max=21) 检查数据行 trx_id=10，10 < 20 且不在 m_ids 中，可见。读取到 200。

3. 可重复读 (Repeatable Read, RR)

在可重复读级别下，InnoDB 使用事务级快照确保事务内读取一致性。

如何解决不可重复读： 保证一个事务内，多次读取同一数据的结果是一致的。InnoDB 实现：

读操作 (SELECT)： 只在第一次执行快照读时生成一个 ReadView，后续所有读操作都复用这个 ReadView。因此，无论其他事务是否提交，本事务看到的永远是“快照”那一刻的数据版本。

写操作 (UPDATE/DELETE) 和 当前读 (SELECT ... FOR UPDATE/SHARE)： 使用行级锁和Next-Key Lock（临键锁） 来防止其他事务修改本事务即将要操作的数据范围，从而避免幻读。

Next-Key Lock： 是行锁（Record Lock） 和间隙锁（Gap Lock） 的结合。它锁住的不仅是一个记录，还包括该记录之前的间隙，防止其他事务在这个范围内插入新数据。

实现特点：

在事务第一次读操作时创建 ReadView整个事务期间使用相同的 ReadView通过 MVCC 避免不可重复读通过 Next-Key 锁避免幻读

RR 级别下的 MVCC 与 Next-Key Lock 示例：

MVCC 部分：

沿用上面的例子，在 T3 时刻事务 B 生成 ReadView 后，在 T5 时刻即使事务 A 提交了，事务 B依然使用旧的 ReadView1进行可见性判断，因此读到的依然是 100，实现了可重复读。

Next-Key Lock 防止幻读：

事务 A：SELECT * FROM employees WHERE age = 25 FOR UPDATE; (当前读，加锁)事务 B：INSERT INTO employees (age) VALUES (25); (被阻塞)

Next-Key 锁是 InnoDB 在可重复读隔离级别下避免幻读的关键技术，它是记录锁(Record Lock)和间隙锁(Gap Lock)的组合。

图片

这条FOR UPDATE语句会在 age=25 的索引记录上加行锁，并在其前后间隙加上间隙锁。事务 B 的插入操作如果 age=25 落在被锁住的间隙（例如插入一个 25），就会被阻塞，从而避免了幻读。

图片

4. 串行化 (Serializable)

实现原理： 最严格的隔离级别。InnoDB 通过强制所有读操作都加上共享锁（SELECT ... FOR SHARE的隐式版本）来实现。读写、写写冲突都会严重，导致大量事务阻塞，性能最差。应用场景： 对数据一致性要求极高，且可以完全接受并发性能损失的场景，如金融核心账务系统。

实践与选择

理解了原理，我们最终要落地到实践。如何选择隔离级别？

1. MySQL 的默认级别：可重复读 (RR)InnoDB 选择 RR 作为默认级别，是因为其通过 MVCC 和 Next-Key Lock 在性能和一致性上取得了很好的平衡。在绝大多数应用场景下，它既能保证事务内数据的一致性（避免不可重复读和幻读），又提供了比串行化高得多的并发性能。

2. 读已提交 (RC) 的适用场景近年来，越来越多的应用选择将隔离级别设置为 RC。原因如下：

减少锁冲突： RR 级别下的 Gap Lock 和 Next-Key Lock 更容易导致死锁，尤其是在复杂的 SQL 语句下。RC 级别没有 Gap Lock，写操作只锁住必要的行，锁冲突和死锁概率大大降低。逻辑清晰： 每次读都能拿到已提交的最新数据，对于很多逻辑简单的应用来说更符合直觉。与 Binlog 格式： 在binlog_format=ROW的情况下，使用 RC 级别的主从复制也是安全的。

选择 RR 还是 RC？

如果你的业务逻辑极度依赖“一个事务内多次读取数据绝对一致”（例如对账、报表统计），那么 RR 是更安全的选择。如果你的业务逻辑以高并发写入为主，且读写冲突不那么严重，或者你希望减少死锁，那么 RC 可能是更好的选择。许多互联网高并发应用都使用 RC 级别。

3. 如何设置和查看隔离级别

查看当前会话隔离级别： SELECT @@transaction_isolation;设置全局隔离级别 (需重启)： SET GLOBAL transaction_isolation = READ-COMMITTED;设置当前会话隔离级别： SET SESSION transaction_isolation = REPEATABLE-READ;

4. 避免“长事务”无论选择哪种隔离级别，长事务都是数据库的大敌。在 RR 级别下，长事务会导致 Undo Log 版本链过长，占用大量存储空间，影响性能。同时，它持有的锁可能长时间不释放，阻塞其他事务。务必监控并优化掉长事务。

总结

MySQL 的事务隔离级别是一个层次分明、权衡精妙的系统。从 RC 到 RR，不仅仅是隔离性的提升，更是 MVCC 从“每次生成视图”到“第一次生成视图”的转变，以及锁机制从“行锁”到“Next-Key Lock”的升级。

希望本文通过原理剖析和图示，能帮助你建立起对 MySQL 事务隔离级别深刻而直观的理解。

下次当你面对“幻读”、“不可重复读”这些问题时，或者当你需要为应用选择合适的隔离级别时，你的决策将会更加自信和准确。

记住，没有最好的隔离级别，只有最适合你业务场景的隔离级别。