MySQL的MVCC底层原理二

承接上文​​MySQL的MVCC底层原理​​

上文说到时序图中的第12步
这篇文章咱接着聊完

​​时序图​​

图1

​​时序图第12步中的查询事务的read-view情况​​

图2

read-view为[100,200],300
即未提交数组事务id为100和200
最大的事务id为300

图3

去id为1的数据的版本链中根据比对规则去查找数据

​​最新的一条数据​​

图4

事务id为100
100在这个查询的未提交的事务数组中
所以这条数据对于当前查询事务是不可见的
那么继续在版本链上找

​​根据回滚指针找到第二条数据​​

图5

和最新的那条数据也是一样的 
这条数据对于当前事务是不可见的
那么继续根据回滚指针找数据

图6

这条数据的事务id是300

图7

事务id为300也是落到黄色部分的区间
根据版本链的对比规则可知
这一行数据的事务id300不在未提交事务的数组中
说明这个版本的数据是已经提交的事务产生的
这是可见的

截止目前找到了这条数据 
就会把这条数据返回

​​继续看下时序图第14和15步骤​​

又更新了2个SQL语句

第14步：
update account set name='人' where id =1;

第15步：
update account set name='笔' where id =1;

​​那么此时id=1的数据版本链是​​

图8

​​时序图第16步​​

select name from account where id =1

图9

可重复读的readview会沿用第一次查询时候的readview[100,200],300

如果已提交读的话每次select都会生成一次最新的readview 未提交事务数组为[200]

​​可重复读readview去最新版本链中找​​

图10

​​先找第一条数据​​

图11

这条数据的事务id为200
200在未提交的事务列表中
那么这条数据所对应的事务对于查询事务来说还未提交 
所以不可见
根据上面说的查询规则 
最终还是找到了

图12

所以第16步即第三次查询查询的结果为上面这条数据

截止目前已经将时序图上的所有环节都描述清楚了

​​接下来修改下时序图​​

图13

将查询事务1去掉
换成了查询事务2
那么时序图中第14步会查询出来什么数据
select name from account where id =1

​​此时的readview和数据版本链是​​

图14

​​第一条数据​​

图15

这条数据的事务id为200

图16

落在黄色区间
那么这条数据对应的事务id=200对于查询事务2
还未提交 
所以不可见
第二条数据也是一样的

​​第三条数据​​

图17

事务id=100是小于min_id=200的
所以落在绿色区间（已提交事务区间）
这个数据对于查询事务2是可见的
所以就会把这条数据返回

再次总结下数据版本链的比对规则

​​得到read-veiw的过程​​

图18

​​版本链对比过程​​

图19

​​图14中的版本链数据​​

其实就是快照数据
记录了历史每个事务对于这条数据的变更记录
并非每个事务都复制了一份这条数据

​​快照数据是针对于全库全表的​​

举例说明
调整下时序图

在查询事务2上添加了步骤8
select * from t；
查询t表
此时就会生成一个readview
那么第15步就会使用这个readview去版本链中比对查询数据

所以任何一个查询事务（session级别的）sql语句生成的readview
是针对全库所有表的快照
在当前事务 查询所有表都会沿用这个readview

​​删除数据​​

对于删除的情况可以认为是update的特殊情况
会将版本链上最新的数据复制一份

这是最原始的一条数据
如果将之删除
首先会复制这一条数据
比如删除的事务id是300

接下来会在复制的这条数据的信息头的标记位写上ture

表明这条记录虽然在版本链中但已经被删除了
再来查询的话 按照刚才说的readview和版本链的比对规则找到了是这条记录
会判断下这条记录头信息中的标记位是否为ture
如果为ture的话 则不会返回
如果这条记录没有任何标记 那么就是符合的
就会返回这条数据