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

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

当trx_id >= low_limit_id,不可以读

当up_limit_id = low_limit_id 的时候,不可以读

当trx_id在范围中间,且当前的记录id,在trx_ids里边,不可以读

其他情况都可以读

读已提交 和 可重复读的不同流程

因为,MVCC要贴合这两个隔离级别解决的问题,所以,他们的流程会有点不一样

对于读已提交来说,事务开始,每一次select都会去获取ReadView

对于可重复读来说,事务开始,到结束,只会获取一次ReadView

这个想想就能明白,读已提交,没有解决不可重复读问题,那么每一次读ReadView的时候,有可能有一些事务就提交了,会读到多的数据

可重复读的时候,由于至始至终,只看一个ReadView,那就是事务开始的时候的ReadView,那可想而知,不会有可重复读的问题,还有幻读的问题了,因为,只看一个ReadView,就算多一万遍,读到的记录还是不会多不会少,所以这也是为什么对于可重复读来说,它可以解决幻读问题了.

RR -> MVCC + Next-key-Lock 防止幻读

对于本篇文章来说,我文中说的,在可重复读的情况下,可以解决幻读问题的

这其实是不严谨的

对于快照读来说,在RR下,是可以解决幻读问题

但是对于当前读来说,因为读到的是最新的数据,还有就是,在undo log中,分为insert log 和 update log,insert log是对其他事务不可见的,所以在RR下,并且是当前读,就有可能出现幻读问题

总结就是一句话,当前读的情况下,如果其他事务做了插入操作,可能会有幻读问题

在RR下,哪些是当前读呢?

select…for update/lock in share mode、insert、update、delete

如此,我们的解决办法就是Next-key-Lock

记录锁 + 间隙锁 = Next-key-Lock

它的原理也很简单,就是在行锁的基础上,锁定范围,如果其他事务要插入到这个范围内的化,会被拒绝

换个角度想就是,我不让你插入,我就不会有幻读问题!

总结

所以我们最后来总结一下

MVCC的目的是什么?

为了解决读-写并发,但是只针对读已提交 + 可重复读

MVCC是怎么实现的?

第一,隐藏字段-> 事务id + 指针

第二,Undo log

第三,ReadView

如何实现这个问题,就转换成ReadView如何做校验?

对于读已提交,每次select的时候,获取一个ReadView

对于可重复读,事务开始的时候,获取一个ReadView

做实际的校验

到最后,做校验的问题,就转换成校验的规则是什么?

如果,trx_id >= low_limit_id,不符合条件

如果,up_limit_id