MVCC案例

文章目录

• • MVCC的执行流程案例
  • • 在隔离级别读已提交的情况下
    • 可重复读（RR）隔离级别

MVCC的执行流程案例

讲之前先看Read view的属性和匹配规则

Read View是如何保证可见性判断的呢？我们先看看Read view 的几个重要属性

1. m_ids:当前系统中那些活跃(未提交)的读写事务ID, 它数据结构为一个List。
2. min_limit_id:表示在生成ReadView时，当前系统中活跃的读写事务中最小的事务id，即m_ids中的最小值。
3. max_limit_id:表示生成ReadView时，系统中应该分配给下一个事务的id值。
4. creator_trx_id: 创建当前read view的事务ID

Read view 匹配条件规则如下：

1. 如果数据事务ID trx_id < min_limit_id，表明生成该版本的事务在生成Read View前，已经提交(因为事务ID是递增的)，所以该版本可以被当前事务访问。
2. 如果trx_id>= max_limit_id，表明生成该版本的事务在生成ReadView后才生成，所以该版本不可以被当前事务访问。
3. 如果 min_limit_id =

• 如果m_ids包含trx_id,则代表Read View生成时刻，这个事务还未提交，但是如果数据的trx_id等于creator_trx_id的话，表明数据是自己生成的，因此是可见的。
• 如果m_ids包含trx_id，并且trx_id不等于creator_trx_id，则Read View生成时，事务未提交，并且不是自己生产的，所以当前事务也是看不见的；
• .如果m_ids不包含trx_id，则说明你这个事务在Read View生成之前就已经提交了，修改的结果，当前事务是能看见的。

在隔离级别读已提交的情况下

我们基于MVCC分析一下流程
1、 A开启事务，首先得到一个事务ID，假如为100
2、B开启一个事务，得到事务ID就为101
3、事务A进行快照读生成一个read view,read view对应的值为下

变量	值
m_ids	100,101
max_limit_id	102
min_limit_id	100
creator_trx_id	100

这里min_limit_id为100，因为就两个事务活跃，最小的刚好是100
max_limit_id为200是因为事务id已经到了101，下一个就是102

在版本链中挑选可见的记录

上图事务id为100，由此可见，最新版本的列的名字为zzz开始进行read view可见性验证

min_limit_id(100)=< trx_id（100）< max_limit_id(102);
creator_trx_id = trx_id =100;

所以trx_id是可见的，查到的名字是zzz

4、事务B更改的时候，会先把原数据拷贝到undo log 里面，并通过隐藏的回滚指针指向 undo log 中的原记录。

解释一下，为什么会先把原数据拷贝到undo log 里面
假设undo log中事务id存放到100，属于历史版本，磁盘里存放的是当前最新的版本事务id为101，要进行更改的时候需要把原数据读到内存中，并拷贝到undo log里，如果不拷贝进去，修改完就无法进行回滚

5、提交事务
6、事务A再次执行查询 *** 作，新生成一个Read view

变量	值
m_ids	100
max_limit_id	102
min_limit_id	100
creator_trx_id	100

== 解释一下为什么m_ids为100，m_ids:当前系统中那些活跃(未提交)的读写事务ID，所以还是100==

min_limit_id(100)= 但是,trx_id=101，不属于m_ids集合

这里解释一下，为什么事务ID（trx_id）为什么是101而不是之前的100
因为第二次read view的时候，事务B已经提交，磁盘里最新数据版本变成101，
100变成了历史版本存放在undo log里

trx_id=101这个记录，对于当前事务是可见的。所以SQL查询到的是name为zxp的记录。

可重复读（RR）隔离级别

注意：在可重复读（RR）隔离级别下，一个事务里只会获取一次read view，都是副本共用的，从而保证每次查询的数据都是一样的。

所以事务A第二次select的时候,不会创建read view，两次查到的数据不变都是zzz
第二次select没有创建read view所以获取的事务id还是100