关于网站开发的期刊如何创建一个自己的网站
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并一直复用，直到事务结束。