InnoDB存储引擎对MVCC的实现
MVCC
MVCC的目的
在搞清楚MVCC之前,我们要搞懂一个问题,MVCC到底解决的是什么问题?
我用一句话概括,那就是为了解决读-写可以一起的问题!
在我们的印象里,InnoDB可以读读并发,不能读写并发,或者写写并发
这是很正常的想法,因为如果读写并发的化,会有并发问题
而对于写写并发来说,我们还是得加锁,这是没办法改的
但是对于读-写并发来说,我们就可以用MVCC来解决
所以,综上所述,MVCC就是为了解决读-写并发,提高性能.
更准确的说,它是针对读操作的!和写操作关系不大
所以在MVCC的加持上,如果要解决并发问题?
读 + MVCC
写 + 锁
解决哪些并发问题?
先说结论:
对于读已提交
MVCC 解决了脏读
对于可重复读
MVCC 解决了脏读 + 不可重复读 + 幻读
然后其次,我们要搞清楚,有四种隔离级别,我相信大家都知道
读未提交 什么都没解决
读已提交 解决了脏读
可重复读 解决了脏读 + 不可重复读
串行 解决了脏读 +不 可重复读 + 幻读
这我相信你也是滚瓜烂熟
那么对于MVCC来说,它实际解决了哪些问题呢? 这个我们就得分情况了,因为MVCC也是贴合四种隔离级别的!我先说这个就是为了有一个大致的方向
需要注意的是,对于MVCC来说,读未提交 和 串行是束手无策的
你想一想就知道,读未提交连脏读都可以容忍,它还要你MVCC来干嘛,直接读就可以了
对于串行来说,它的读 + 写都是串行化的,不管你读还是写,都要排队,根本没有读 - 写并发的情况
所以,我们需要明确一点,MVCC是针对读已提交 + 可重复读
想清楚这一点,我们再来分别看,MVCC解决的问题,你可能会问,既然你都是贴合四种隔离级别的,那不就是对应隔离级别解决的问题嘛,不是的,这里就是有一个特殊,所以我才会拿来说
对于读已提交
MVCC 解决了脏读
对于可重复读
MVCC 解决了脏读 + 不可重复读 + 幻读
那么比较特殊的一点就是,对于可重复读来说,多解决了一个幻读的问题
综上所述,我们的结论就是,MVCC是针对读已提交 + 可重复读,并且在可重复读的情况下,还多解决了一个幻读问题
如何实现的?
读到这里,你就很好奇了,它是如何实现的呢?
其实很简单,就是一句话,MVCC读的是副本,不是当前的当前正在并发的数据
我们来反过来想,为什么会出现脏读 + 不可重复读,就是因为事务在并发的时候,有可能会修改你正在读的数据,这就导致,读第二次的时候会出现不一致
那我们该如何解决呢?也很简单,就是在事务一开始的时候,保存一份当前数据的副本,这样就算其他事务修改了,它修改的是数据库的数据,而不是我们的副本,这样不就避免了这两个问题吗?
顺着这个思路想,如果每次事务一开始的时候,我们都要取保存一份当前数据的副本,那如果有上亿的读的访问的话,那不是内存炸了?
所以,我们得用MySQL现成的功能来实现这个副本的功能!
所以,自然而然你会想到,Undo log,只有它存着历史的数据,那就是刚刚好的
至此,我们大致就可以引出了三个依赖
第一,隐藏字段
第二,Undo log
第三,Read View
Undo log就不用说了,就是为了生成副本的
Read View 也好说,不过是副本的官方的名字
对于隐藏字段来说,我们就得说一说了
对于聚簇索引来说,他有必要的隐藏列,
trx_id: 事务id
roll_pointer: 指针
事务id,就不用多说了,你需要一个标识来标识事务
对于roll_pointer来说,它和Undo log就会有联系,就是一个指针嘛,我们直接看图就能懂了,为什么需要roll_pointer,还有Undo log实际上长什么样子
一看就懂,不就是链表嘛,第一个就是最新的记录,后边的都是历史记录
此时,你就大概能明白,为什么需要隐藏字段了把,其实也不是很重要,一笔带过就行
我们特别要注意的是,Read View 副本的结构,这才是我们需要研究的东西
因为我们不熟啊
Read View结构
对于Read View我们先看图,它的大致结构如下
实际,它记录的不是实际的数据,而是一群活跃的事务id
什么叫活跃的事务id呢?就是那些在并发的时候,在那捣乱的事务,为啥要记录呢?很好理解嘛,在Undo log中,只要有这些捣蛋鬼做的记录,我们就不看,读那些已经提交的记录
结构
creator_trx_id: 创建Readview的事务id
trx_ids: 活跃的事务id列表
up_limit_id: 最小的事务ID
low_limit_id: 下一个最大的事务ID
这里需要特别注意,up_limit_id是最小的
low_limit_id是最大的
还有一点是,这里的最小最大的选取标准是不一样的
这里举个例子,比较容易懂
比如说,事务id列表中,有三个事务id, 1,3,5
我们要假设MySQL只有这三个事务id,其他没有,暗含的意思是,这里的id = 5,是当前生成的最大的事务id
那么up_limit_id 就是1
low_limit_id 是当前生成过的最大的事务id + 1 也就是 5 + 1 = 6
假设事务5提交了,此时的事务列表是1,3
low_limit_id 还是6,因为它类似于Auto_increment 自增id的意思,它会记录当前生成过的最大的事务ID
ReadView的规则
我们研究这个规则,实际上就是研究MVCC的核心规则了
我们得对应着Undo log的版本链来看,版本链就是历史记录
如下
然后就着
ReadView的结构来看
事务开始,生成一个ReadView,
然后当前事务,要读取的时候,此时就会去查看两个东西 ReadView + Undo log
查看Undo log就是顺着链表一个一个往下看,找到符合条件的就返回
符合的条件就是规则
第一,如果此时查看的记录trx_id = creator_trx_id,符合条件,读此记录
意思就是,当前记录就是我们自己事务干的事,ReadView是我们当前事务自己生成的,自己读自己的,当然没问题
第二,如果不是自己的,就检查,ReadView的trx_ids,也就是事务id列表
如果发现,当前访问的记录,就是这些捣蛋鬼其中一个干的,那就是不符合条件,如果发现不在这群事务id里边,说明,当前读的是,已经提交了的记录,符合条件
第三,需要注意的是,对于第二,来说,当前的记录的trx_id是介于
up_limit_id < 当前 事务id < low_limit_id,
up_limit_id,和low_limit_id,是一个范围,还有一个功能就是快速的判断
如果,最新的记录是小于up_limit_id的,那么直接就是返回当前记录
为什么呢?因为事务id是单调递增的,和主键id一样,如果我们最新的记录都提交了,那更早的记录是不是都提交了,返回返回没问题!
如果,最新的记录是大于等于low_limit_id的,那么不符合条件,往下找
为什么呢? 因为,如果此时最新的记录是大于low_limit_id的,意思就是这个记录它是在我们事务生成ReadView之后生成的,也就是
我们生成ReadView
然后紧接着,有一个事务进来修改了
那更不可能读这条记录了,比迟到的人还迟到.
综上所述,我们总结一下
trx_id = creator_trx_id,可以读
当trx_id < up_limit_id,可以读
当trx_id >= low_limit_id,不可以读
当up_limit_id <= trx_id < low_limit_id的时候,查看当前记录的id是不是在trx_ids里边,如果在的话,说明这是捣蛋鬼干的,不可以读,如果不存在,可以读
再总结一下,我们只要记住什么时候不可以读
当trx_id >= low_limit_id 的时候,不可以读
当trx_id在范围中间,且当前的记录id,在trx_ids里边,不可以读
其他情况都可以读
读已提交 和 可重复读的不同流程
因为,MVCC要贴合这两个隔离级别解决的问题,所以,他们的流程会有点不一样
对于读已提交来说,事务开始,每一次select都会去获取ReadView
对于可重复读来说,事务开始,到结束,只会获取一次ReadView
这个想想就能明白,读已提交,没有解决不可重复读问题,那么每一次读ReadView的时候,有可能有一些事务就提交了,会读到多的数据
可重复读的时候,由于至始至终,只看一个ReadView,那就是事务开始的时候的ReadView,那可想而知,不会有可重复读的问题,还有幻读的问题了,因为,只看一个ReadView,就算多一万遍,读到的记录还是不会多不会少,所以这也是为什么对于可重复读来说,它可以解决幻读问题了.
总结
所以我们最后来总结一下
MVCC的目的是什么?
为了解决读-写并发,但是只针对读已提交 + 可重复读
MVCC是怎么实现的?
第一,隐藏字段-> 事务id + 指针
第二,Undo log
第三,ReadView
如何实现这个问题,就转换成ReadView如何做校验?
对于读已提交,每次select的时候,获取一个ReadView
对于可重复读,事务开始的时候,获取一个ReadView
做实际的校验
到最后,做校验的问题,就转换成校验的规则是什么?
如果,trx_id >= low_limit_id,不符合条件
如果,up_limit_id <= trx_id < low_limit_id,并且trx_id在trx_ids中,不符合条件
其他情况都符合