mysql mvcc实现原理详解-MySQL MVCC原理-原理解释-妙笔生花阁

猜您喜欢：：

MySQL MVCC实现原理详解：深入解析多版本并发控制

MySQL MVCC 实现原理详解：解锁高并发下的读写平衡

在 MySQL 的 InnoDB 存储引擎中，MVCC（Multi-Version Concurrency Control，多版本并发控制）是支撑其高并发性能的核心机制之一。它允许数据库在读写操作之间实现非阻塞的并发，极大地提升了系统的吞吐量。然而，许多开发者对 MVCC 的理解往往停留在“它能提高并发”这一表面概念上，而对其底层实现机制——特别是如何与事务隔离级别、锁机制配合工作——缺乏深入认知。本文将深入剖析 MySQL MVCC 的实现原理，结合数据结构、事务快照及隔离级别，为你揭开其神秘面纱。

一、为什么需要 MVCC？

在没有 MVCC 的传统数据库中，读写操作往往互斥。例如，当一个事务正在读取某行数据时，另一个事务试图更新该行，读取操作可能需要等待写锁释放，或者写操作需要等待读锁释放。这会导致严重的性能瓶颈。 MVCC 的核心思想是：保留数据的历史版本，使得在读取和写入冲突时，不需要加锁，而是通过读取数据的某个历史版本来实现非阻塞的并发。关键优势： 1. 提高并发性能：大多数情况下，读操作不加锁。 2. 解决脏读：保证事务看到的都是已提交的数据。 3. 平衡一致性与性能：在可重复读（RR）和读已提交（RC）隔离级别下，提供不同级别的一致性保证。

二、 MVCC 的三大基石

MVCC 的实现依赖于 InnoDB 表中的三个隐藏字段。理解这些字段是掌握 MVCC 的前提。

1. 隐藏字段详解

字段名称	作用	说明
DB_TRX_ID	事务 ID	最近修改该行数据的事务 ID。如果是插入操作，记录的是插入事务的 ID。
DB_ROLL_PTR	回滚指针	指向该行数据的旧版本（Undo Log）。通过该指针可以形成一条版本链。
DB_ROW_ID	隐藏行 ID	如果表没有主键，InnoDB 会自动生成一个唯一的 6 字节行 ID。

2. 版本链（Version Chain）

当一行数据被多次更新时，InnoDB 不会直接覆盖原数据，而是通过 `DB_ROLL_PTR` 将旧版本链接起来，形成一条版本链。 ```text [当前版本: TRX_ID=10, RollPtr->V2] ↓ [V2: TRX_ID=8, RollPtr->V1] ↓ [V1: TRX_ID=5, RollPtr->NULL] ```

最新可见版本：事务在读取时，会根据当前事务的隔离级别和快照信息，从版本链中找到一个符合可见性规则的数据版本。
Undo Log：旧版本数据存储在 Undo Log 中，而非主数据页中，以节省空间并提高性能。

3. Read View（读视图）

Read View 是 MVCC 实现快照读的核心。它记录了当前事务在读取时刻的“系统状态”，用于判断某个数据版本对当前事务是否可见。 Read View 包含以下关键信息：

字段	说明
m_ids	当前活跃事务 ID 列表（即未提交的事务 ID）。
min_trx_id	m_ids 中最小的事务 ID。
max_trx_id	下一个将要被分配的事务 ID（即当前最大事务 ID + 1）。
creator_trx_id	创建该 Read View 的事务 ID。

三、可见性判断规则

当一个事务读取某行数据时，InnoDB 会根据当前事务的隔离级别生成一个 Read View，并利用以下规则判断版本链中的哪个版本对当前事务可见。

通用判断规则

设当前事务的事务 ID 为 `current_trx_id`，数据版本的事务 ID 为 `version_trx_id`： 1. 如果 `version_trx_id < min_trx_id`：

说明该版本在事务开始前就已经提交，可见。

2. 如果 `version_trx_id >= max_trx_id`：

说明该版本是在事务开始后才创建或提交的，不可见。

3. 如果 `min_trx_id <= version_trx_id < max_trx_id`：

需要进一步判断 `version_trx_id` 是否在 `m_ids`（活跃事务列表）中。
如果 `version_trx_id` 在 `m_ids` 中，说明该事务尚未提交，不可见。
如果 `version_trx_id` 不在 `m_ids` 中，说明该事务已提交，可见。

注意：如果 `version_trx_id creator_trx_id`，即当前事务自己修改的数据，直接可见。

四、隔离级别与 MVCC 的关系

MySQL 提供了四种事务隔离级别，其中读已提交（RC）和可重复读（RR）支持 MVCC，而读未提交（RU）和串行化（SERIALIZABLE）不支持或不完全支持。

1. 读已提交（Read Committed, RC）

快照生成时机：每次执行 `SELECT` 查询时，都会生成一个新的 Read View。
特点：
允许“不可重复读”：在同一个事务中，两次读取同一行数据可能得到不同结果。
每次查询都基于最新的已提交数据。

2. 可重复读（Repeatable Read, RR）

快照生成时机：在事务的第一次 `SELECT` 查询时生成 Read View，后续查询复用该快照。
特点：
保证“可重复读”：在同一个事务中，多次读取同一行数据结果一致。
解决“幻读”问题：通过 Next-Key Lock 和 MVCC 共同作用，RR 级别下大部分情况下可避免幻读。

3. 对比总结

特性	读已提交（RC）	可重复读（RR）
Read View 生成时机	每次 SELECT 时生成	事务中第一次 SELECT 时生成
可见性	基于最新已提交版本	基于事务开始时的快照
不可重复读	可能出现	不会出现
幻读	可能出现	大部分情况不会出现（需配合 Next-Key Lock）
适用场景	对一致性要求不高，追求高并发	大多数业务场景，保证数据一致性

五、快照读 vs 当前读

理解 MVCC 必须区分两种读取方式：

类型	说明	是否加锁	示例
快照读（Snapshot Read）	读取数据的快照版本，基于 MVCC，不加锁	否	`SELECT FROM table WHERE id=1;`
当前读（Current Read）	读取数据的最新版本，加锁（共享锁或排他锁）	是	`SELECT ... FOR UPDATE;` `SELECT ... LOCK IN SHARE MODE;` `INSERT`, `UPDATE`, `DELETE`

快照读：利用 MVCC 实现非阻塞读取，性能高。
当前读：用于需要获取最新数据或修改数据的场景，会阻塞其他事务的读取或写入，确保数据一致性。

六、实战案例演示

假设有一个表 `users`，初始数据为： ```sql INSERT INTO users (id, name) VALUES (1, 'Alice'); ```

场景一：RC 隔离级别下的不可重复读

事务 A： ```sql BEGIN; SELECT name FROM users WHERE id = 1; 返回 'Alice' ``` 事务 B（在事务 A 之后执行）： ```sql BEGIN; UPDATE users SET name = 'Bob' WHERE id = 1; COMMIT; ``` 事务 A（继续执行）： ```sql SELECT name FROM users WHERE id = 1; 在 RC 下，返回 'Bob' COMMIT; ``` 结果：事务 A 两次读取结果不同，因为每次 SELECT 都生成了新的 Read View，看到了事务 B 提交的最新版本。

场景二：RR 隔离级别下的可重复读

事务 A： ```sql BEGIN; SELECT name FROM users WHERE id = 1; 返回 'Alice' ``` 事务 B： ```sql BEGIN; UPDATE users SET name = 'Bob' WHERE id = 1; COMMIT; ``` 事务 A（继续执行）： ```sql SELECT name FROM users WHERE id = 1; 在 RR 下，仍返回 'Alice' COMMIT; ``` 结果：事务 A 两次读取结果相同，因为第一次 SELECT 时生成的 Read View 在事务 A 整个生命周期内复用，看不到事务 B 的修改。