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

Mysql中MVCC的流程

news 2025/11/3 13:09:39

一、核心概念

表中每行数据的3个隐式字段：

事务ID（Transaction ID）
DB_TRX_ID：每行记录都有一个隐藏字段 DB_TRX_ID（6字节），记录最后修改该行数据的事务ID（是修改的事务ID,不管修改有没有提交，只要是修改了，那么就是谁的事务ID）, 事务ID是全局自增的，新事务会获得一个比之前所有事务都大的ID

回滚指针（Rollback Pointer）
DB_ROLL_PTR：另一个隐藏字段（7字节），指向该行数据在 undo log 中的历史版本, 形成一条版本链，可以追溯到数据的各个历史状态

Read View（读视图）
当事务执行快照读（普通SELECT）时，会生成一个Read View，

包含：

1、creator_trx_id：创建此Read View的事务ID，如果是快照读创建的是一个虚拟线程。
2、m_ids：生成Read View时，系统中活跃（未提交）的事务ID集合
3、min_trx_id：m_ids中的最小值
4、max_trx_id：下一个将要分配的事务ID（当前最大事务ID+1）ReadV iew包含的内容 {creator_trx_id,  // 创建者事务ID（虚拟或真实）m_ids[],         // 活跃事务ID列表min_trx_id,      // 最小活跃事务IDmax_trx_id       // 下一个将分配的事务ID
}

流程：

-- 初始数据: id=1, balance=1000 (TRX_ID=100, 已提交)-- 时间线:
T1: 事务200开始, UPDATE → balance=800 (未提交)
T2: 事务300开始, UPDATE → balance=600 (已提交)  
T3: 事务400开始, UPDATE → balance=400 (未提交)
T4: 事务500执行SELECT查询(快照读)  为什么事务是从400开始，不应该是从100开始算吗？ 这里有个误解就是，没提交的事务，也会刷到数据页中，可以看下面的问题3。

– 版本链:

v4(TRX_ID=400, balance=400) 
← v3(TRX_ID=300, balance=600) 
← v2(TRX_ID=200, balance=800) 
← v1(TRX_ID=100, balance=1000)

事务500的Read View和判断过程

事务500创建：Read View：
1、creator_trx_id= 500 (或虚拟ID)
2、m_ids= [200, 400]  (活跃事务：200和400，300已提交)
3、min_trx_id= 200
4、max_trx_id= 501

1、遍历判断过程：
检查v4 (TRX_ID=400)：
400 ∈ m_ids [200,400] → 活跃事务 → 不可见
沿ROLL_PTR找v32、检查v3 (TRX_ID=300)：
300 ∉ m_ids [200,400] → 不在活跃列表
min_trx_id=200 ≤ 300 < max_trx_id=501 → 在范围内
不在活跃列表中 → 可见
返回v3的数据：balance=600

问题：

1、如果2个快照读的线程并发过来，二者在同一个时刻创建Read View，那么Read View里面的内容是不是一样的？

是的。每来一个快照读都会创建一个Read View。

2、只要开启事务，不管有没有提交，都会出现在版本链中吗？

开启了事务，并不会直接记录到版本链中，只有修改了数据，不管是有提交还是没提交，都会在版本链中。

3、行数据中，隐藏事务ID，一定是事务提交的吗？

不一定，如果事务未提交，也会直接刷到数据页中，这个和以往我们的认知有差异的。
也就是说：DB_TRX_ID 的真实含义，DB_TRX_ID 记录的是"最后修改者"，不是"最后提交者"：

例子

修改前数据行: 
id=1, balance=1000, DB_TRX_ID=100, DB_ROLL_PTR=0x1234修改后（事务200未提交）数据行: 
id=1, balance=800, DB_TRX_ID=200, DB_ROLL_PTR=0x5678
Undo Log: balance=1000, DB_TRX_ID=100, DB_ROLL_PTR=0x1234

为什么这样设计？

-- 传统数据库的写法（不是InnoDB）：
-- 1. 拷贝数据到临时区域
-- 2. 修改临时副本
-- 3. 事务提交时替换原数据-- InnoDB的实际做法：
-- 1. 立即在数据页上修改（创建新版本）
-- 2. 旧版本进入Undo Log
-- 3. MVCC机制控制可见性

性能优化，立即修改数据页的好处：
减少内存拷贝：避免数据来回拷贝
利用缓存局部性：直接修改缓冲池中的数据
简化恢复机制：Redo Log只需记录物理变化

崩溃恢复的考虑

// 崩溃恢复时，检查数据行的DB_TRX_ID
if (row->DB_TRX_ID对应的事务未提交) {// 使用Undo Log回滚修改rollback_row_using_undo_log(row);
} else {// 事务已提交，数据有效keep_row_changes(row);
}
怎么避免读到事务200修改的数据800，通过MVCC。