深入理解MySQL中的MVCC机制

原创已于 2025-12-21 20:59:57 修改 · 468 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#MySQL #MVCC #并发控制 #数据库原理

于 2025-12-21 20:59:16 首次发布

深入理解MySQL中的MVCC机制

引言

在现代数据库系统中，高并发访问是常见场景。为了在保证数据一致性的同时提高并发性能，MySQL引入了多版本并发控制（Multi-Version Concurrency Control，简称MVCC）机制。本文将详细解析MVCC的工作原理、实现方式、应用场景以及与隔离级别的关系，帮助读者全面掌握这一核心概念。

1. 什么是MVCC？

MVCC是一种用于解决并发事务中读写冲突的技术。它通过为每行数据维护多个版本来实现非阻塞的读操作，从而提升系统的并发性能。

核心思想：

读不加锁：读操作不会阻塞其他事务的写操作，也不会被写操作阻塞。
写不阻塞读：写操作不会影响正在进行的读操作。
基于版本管理：每个数据行都有一个或多个版本，由事务ID（Transaction ID）标识。

2. MVCC的关键组成部分

2.1 事务ID（Transaction ID）

每个事务启动时会被分配一个唯一的递增事务ID。
事务ID是全局唯一的，用于判断事务的先后顺序。

2.2 伪列：`DB_TRX_ID`、`DB_ROLL_PTR`、`DB_ROW_ID`

列名	说明
`DB_TRX_ID`	记录该行最新修改的事务ID
`DB_ROLL_PTR`	指向回滚段（Undo Log）中该行旧版本的指针
`DB_ROW_ID`	隐式主键，用于唯一标识一行数据

⚠️ 注意：这些列是InnoDB内部使用的，用户无法直接访问。

2.3 Undo Log（回滚日志）

用于存储数据行的历史版本。
当事务更新某行数据时，旧版本会被保存到Undo Log中，并通过DB_ROLL_PTR链接。
支持事务回滚和MVCC读取历史版本。

3. MVCC如何工作？

3.1 读操作流程（快照读）

事务开始时，记录当前系统中活跃的事务列表（Read View）。
读取数据时，根据DB_TRX_ID与当前事务的Read View比较，决定是否可见。
只返回在该事务开始前已提交的版本。

✅ 举例：事务T1在时间点1开始，此时已有事务T0已提交。当T1读取某行数据时，只会看到T0提交的版本，而看不到后续未提交的更改。

3.2 写操作流程（当前读）

事务修改数据时，先生成新版本。
将新版本写入数据页，并更新DB_TRX_ID。
旧版本存入Undo Log，通过DB_ROLL_PTR指向。
事务提交后，DB_TRX_ID标记为已提交状态。

4. Read View 的作用

Read View 是事务在开始时创建的一个“快照”，决定了哪些版本的数据对当前事务可见。

Read View 包含以下信息：

m_ids：当前活跃的事务列表（未提交的事务）。
min_trx_id：最小的未提交事务ID。
max_trx_id：最大的事务ID（尚未分配）。
creator_trx_id：创建该Read View的事务ID。

可见性规则（基于Read View）：

如果DB_TRX_ID < min_trx_id → 可见（已提交且早于当前事务）。
如果DB_TRX_ID >= max_trx_id → 不可见（未来事务，还未发生）。
否则，如果DB_TRX_ID在m_ids中 → 不可见（正在运行的事务）。
其他情况 → 可见（已提交但发生在当前事务之后）。

💡 示例：假设当前Read View的min_trx_id=5, max_trx_id=10, m_ids=[6,7]，那么：

事务5的版本：可见（<5）
事务8的版本：不可见（在m_ids中）
事务11的版本：不可见（≥10）
事务9的版本：可见（不在m_ids中，且在[5,10)之间）

5. MVCC与隔离级别的关系

隔离级别	是否使用MVCC	说明
READ UNCOMMITTED	否	直接读取最新版本，不考虑事务提交状态
READ COMMITTED	是	每次查询都重新生成Read View，能看到已提交的新数据
REPEATABLE READ	是	仅在事务开始时生成一次Read View，保证一致性视图
SERIALIZABLE	否	使用锁机制，不依赖版本控制