面试官：谈谈你对Mysql的MVCC的理解?

MVCC(Mutil-Version Concurrency Control)，就是多版本并发控制。MVCC 是一种并发控制的方法，通常在数据库管理系统中，实现对数据库的并发访问。

在Mysql的InnoDB引擎中就是指在已提交读(READ COMMITTD)和可重复读(REPEATABLE READ)这两种隔离级别下的事务对于SELECT操做会访问版本链中的记录的过程。

这就使得别的事务能够修改这条记录，反正每次修改都会在版本链中记录。SELECT能够去版本链中拿记录，这就实现了读-写，写-读的并发执行，提高了系统的性能。

咱们来具体看看是如何实现的。

版本链

咱们先来理解一下版本链的概念。在InnoDB引擎表中，它的聚簇索引记录中有两个必要的隐藏列：

• trx_id

这个id用来存储的每次对某条聚簇索引记录进行修改的时候的事务id。

• roll_pointer

  每次对哪条聚簇索引记录有修改的时候，都会把老版本写入undo日志中。这个roll_pointer就是存了一个指针，它指向这条聚簇索引记录的上一个版本的位置，经过它来得到上一个版本的记录信息。(注意插入操做的undo日志没有这个属性，由于它没有老版本)

好比如今有个事务id是60的执行的这条记录的修改语句

此时在undo日志中就存在版本链

ReadView

说了版本链咱们再来看看ReadView。已提交读和可重复读的区别就在于它们生成ReadView的策略不一样。

ReadView中主要就是有个列表来存储咱们系统中当前活跃着的读写事务，也就是begin了还未提交的事务。经过这个列表来判断记录的某个版本是否对当前事务可见。假设当前列表里的事务id为[80,100]。

• 若是你要访问的记录版本的事务id为50，比当前列表最小的id80小，那说明这个事务在以前就提交了，因此对当前活动的事务来讲是可访问的。

• 若是你要访问的记录版本的事务id为70,发现此事务在列表id最大值和最小值之间，那就再判断一下是否在列表内，若是在那就说明此事务还未提交，因此版本不能被访问。若是不在那说明事务已经提交，因此版本能够被访问。

• 若是你要访问的记录版本的事务id为110，那比事务列表最大id100都大，那说明这个版本是在ReadView生成以后才发生的，因此不能被访问。

这些记录都是去版本链里面找的，先找最近记录，若是最近这一条记录事务id不符合条件不可见的话，再去找上一个版本再比较当前事务的id和这个版本事务id看版本能不能访问，以此类推直到返回可见的版本或者结束。

举个例子 ，在已提交读隔离级别下：

好比此时有一个事务id为100的事务，修改了name,使得的name等于小明2，可是事务还没提交。则此时的版本链是

那此时另外一个事务发起了select 语句要查询id为1的记录，那此时生成的ReadView 列表只有[100]。那就去版本链去找了，首先确定找最近的一条，发现trx_id是100,也就是name为小明2的那条记录，发如今列表内，因此不能访问。

这时候就经过指针继续找下一条，name为小明1的记录，发现trx_id是60，小于列表中的最小id,因此能够访问，直接访问结果为小明1。

那这时候咱们把事务id为100的事务提交了，而且新建了一个事务id为110也修改id为1的记录，而且不提交事务

这是时候版本链就是

这时候以前那个select事务又执行了一次查询,要查询id为1的记录。

这个时候关键的地方来了

若是你是已提交读隔离级别，这时候你会从新一个ReadView，那你的活动事务列表中的值就变了，变成了[110]。

按照上的说法，你去版本链经过trx_id对比查找到合适的结果就是小明2。

若是你是可重复读隔离级别，这时候你的ReadView仍是第一次select时候生成的ReadView, 也就是列表的值仍是[100]。因此select的结果是小明1。因此第二次select结果和第一次同样，因此叫可重复读！

也就是说已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView,而可重复读隔离级别则在第一次读的时候生成一个ReadView，以后的读都复用以前的ReadView。

这就是Mysql的MVCC,经过版本链，实现多版本，可并发读-写，写-读。经过ReadView生成策略的不一样实现不一样的隔离级别。

---

若有错误欢迎指正！

我的公众号:yes的练级攻略

有相关面试进阶(分布式、性能调优、经典书籍pdf)资料等待领取