当前位置：首页 > article >正文

MySQL MVCC工作流程详解

article 2026/1/20 12:57:26

MySQL MVCC工作流程详解

1. 基础概念

MVCC（多版本并发控制）是通过在每行记录后面保存多个版本来实现并发控制的技术，主要用于提供并发事务访问数据库时的读一致性。

2. 核心要素

2.1 事务ID（DB_TRX_ID）

每个事务都有一个唯一的事务ID
事务ID是自增的
事务开始时分配事务ID

2.2 快照读与当前读

快照读（Snapshot Read）：
- 普通的SELECT操作
- 读取的是快照数据
- 不加锁，不阻塞其他事务
当前读（Current Read）：
- SELECT … FOR UPDATE
- SELECT … LOCK IN SHARE MODE
- INSERT/UPDATE/DELETE
- 读取最新数据，需要加锁

3. 实现机制

3.1 隐藏字段

每行记录都包含三个隐藏字段：

1. DB_TRX_ID（事务ID）：最后一次修改该行的事务ID
2. DB_ROLL_PTR（回滚指针）：指向这条记录的上一个版本
3. DB_ROW_ID（行ID）：如果没有主键，InnoDB自动生成

3.2 Undo Log版本链

记录1 (trx_id=50)↓ roll_ptr
记录1历史版本 (trx_id=30)↓ roll_ptr
记录1历史版本 (trx_id=10)↓ roll_ptrNULL

3.3 ReadView组成

creator_trx_id: 创建该ReadView的事务ID
trx_ids: 活跃的事务ID列表
up_limit_id: 活跃事务中最小的事务ID
low_limit_id: 下一个将被分配的事务ID

4. 可见性判断流程

4.1 判断规则

1. 如果记录的trx_id < up_limit_id- 该版本在ReadView创建前已提交- 结论：可见2. 如果记录的trx_id >= low_limit_id- 该版本在ReadView创建后才生成- 结论：不可见3. 如果up_limit_id <= trx_id < low_limit_id- 如果trx_id在活跃事务列表中：不可见- 如果trx_id不在活跃事务列表中：可见

4.2 ReadView创建时机

-- READ COMMITTED：每次读取都创建新ReadView
SELECT * FROM table;  -- 创建新ReadView
SELECT * FROM table;  -- 再次创建新ReadView-- REPEATABLE READ：首次读取创建ReadView并复用
START TRANSACTION;
SELECT * FROM table;  -- 创建ReadView
SELECT * FROM table;  -- 复用已有ReadView

5. 具体案例分析

5.1 READ COMMITTED下的案例

-- 事务A
START TRANSACTION;  -- trx_id = 100
UPDATE user SET name = 'Tom' WHERE id = 1;
COMMIT;-- 事务B
START TRANSACTION;  -- trx_id = 101
SELECT * FROM user WHERE id = 1;  -- 创建ReadView1
-- 此时看不到Tom，因为创建ReadView时事务A在活跃列表中SELECT * FROM user WHERE id = 1;  -- 创建ReadView2
-- 此时能看到Tom，因为新的ReadView中事务A已经不在活跃列表中

5.2 REPEATABLE READ下的案例

-- 事务A
START TRANSACTION;  -- trx_id = 100
SELECT * FROM user WHERE id = 1;  -- 创建ReadView
-- 记录name = 'Jack'-- 事务B执行并提交：UPDATE user SET name = 'Tom' WHERE id = 1;SELECT * FROM user WHERE id = 1;  -- 复用之前的ReadView
-- 仍然看到name = 'Jack'，因为使用的是同一个ReadView

6. 注意事项

6.1 MVCC的局限性

只在RC和RR隔离级别生效
只对DML语句有效
不能解决幻读的所有场景

6.2 性能优化建议

避免长事务
- 长事务会保留过多的历史版本
- 增加存储空间开销
- 影响并发性能
合理使用隔离级别
- 一般建议使用RR级别
- 特殊场景可以考虑RC级别
定期清理Undo Log
- 避免Undo表空间过大
- 及时释放无用的历史版本

7. 总结

不同的隔离级别中,生成read-view的策略不同:
读已提交:每次执行查询sql时都会重新生成最新的read-view
可重复读:执行事务中第一条查询sql时生成read-view,并且事务结束之前都不会发生变化
作用:支持数据并发修改场景下的快照读

实现原理：
readview 和 undolog 记录的数据进行匹配，对得上就去读 undolog 记录的最新数据
undolog 版本链 (行数据维度)：
undolog版本链是指一行数据被多个事务依次修改过后,在每个事务修改完后,MySQL会保留修改前的数据到undo回滚日志,并且用trx_id(事务id)和roll_pointer(回滚指针)两个隐藏字段把这些undolog串联起来形成一个历史记录版本链
readview 机制 (事务维度)：
4个标志位：
m_ids:当前活跃的事务id列表
min_trx_id:当前活跃事务列表中最小的事务id
max_trx_id:下一个将被分配的事务id
creator_trx_id:创建当前readview的事务id
readview 的作用:判断当前事务能看见哪个版本的数据,可见性算法:
如果数据被删除,那么该数据的undolog中roll_pointer指向的undo log
记录就是当前事务能看见的该数据的历史版本
如果数据没有被删除,那么该数据的undolog中roll_pointer指向的undo log

MVCC 如何根据 readview 结合行数据的 undolog 版本链过滤数据的？
先明确定义：行数据的最新 undolog 事务 id
按照顺序判断：
比最小的小,一定读:行数据的最新undolog事务id比min_trx_id还小,说明这个产生这条undolog的事务在readview产生时刻已经被提交了。如果行数据的最新undolog事务id和当前事务id相等,那说明是当前事务修改的数据,那肯定可读。
如果行数据的最新undolog事务id在当前活跃事务id列表内,那也一定读不到,因为活跃事务id列表都是readview生成的一瞬间还没有提交的事务,没提交当然不能读比最大的大,一定不读:行数据的最新undolog事务id比最大事务id还大说明产生这条undolog的事务在readview产生时刻都还没有开启,那肯定读不到
如果最终判断行数据的最新undolog事务id读取不到数据,那么就会根据undolog版本链继续往前一个节点,获取新的事务id重新对比,继续过滤,直到找到一个符合规则的数据

RR 隔离级别下，采用当前读是否会重复生成 ReadView?
不会，RR隔离级别下，事务中第一次执行当前读时，会生成ReadView并一直复用，直到事务结束。