MVCC机制依赖于undo log多版本链条+ReadView机制实现，下面我们来逐步分析。

ReadView机制

这个ReadView，简单来说，就是执行一个事务的时候，给你生成一个ReadView，里面比较关键的东西有4个：

• 一个是m_ids，这个就是说此时有哪些事务在MySQL里执行还没提交；
• 一个是min_trx_id，就是m_ids里最小的值；
• 一个是max_trx_id，是mysql下一个要生成的事务id，就是最大事务id；

• 一个是creator_trx_id，就是你这个事务的id。
  我们现在来看一个例子：假设数据库原来就有一行数据，很早以前就有事务插入过了，事务id是32，它的值就是初始值。接着呢，此时两个事务并发过来执行了，一个是事务A（id=45），一个是事务B（id=59），事务B是要去更新这行数据，事务A是要去读取这行数据的。我们看下图：

  
  
  mvcc4.jpg
  
  

  现在事务A直接开启一个ReadView，这个ReadView里的m_ids就包含了事务A和事务B的两个id，然后min_trx_id就是45，max_trx_id就是60，creator_trx_id就是45，是事务A自己。这个时候事务A第一次查询这行数据，会走一个判断，就是判断一下当前这行数据的trx_id是否小于ReadView中的min_trx_id，此时发现trx_id=32，是小于ReadView里的min_trx_id就是45的，说明事务开启之前，修改这行数据的事务早就提交了，所以此时可以查询到这行数据。

接着事务B开始动手了，它把这行数据的值修改为了B值，然后这行数据的trx_id设置为自己的id，也就是59，同时roll_pointer指向了修改之前生成的一个undo log，接着这个事务B就提交了。这个时候事务A再次查询，会发现一个问题，那就是此时数据行里的trx_id=59，那么这个trx_id是大于ReadView里的min_trx_id(45)，同时小于ReadView里的max_trx_id(60)的，说明更新这条数据的事务，很可能就跟自己差不多同时开启的，于是会看一下这个trx_id=59，是否在ReadView的m_ids列表里。果然，在ReadView的m_ids列表里有45和59两个事务id，直接证实了这个修改数据的事务是跟自己同一时段并发执行然后提交的，所以对这行数据是不能查询的。

那么既然这行数据不能查询，那查什么呢？简单，顺着这条数据的roll_pointer找到undo log日志链条，就会找到最近一条undo log，trx_id=32，此时发现它是小于ReadView里的min_trx_id(45)的，说明这个undo log版本必然是在事务A开启之前就执行且提交的。那么就查询最近的那个undo log里的值好了，这就是undo log多版本链条的作用，它可以保存一个快照链条，让你可以读到之前的快照值。如下图：

readView1.jpg

接着假设事务A自己更新了这行数据的值，改成A值，trx_id修改为45，同时保存之前事务B修改的值的快照。此时事务A来查询这条数据的值，会发现这个trx_id=45，居然跟自己的ReadView里的creator_trx_id(45)是一样的，说明这行数据就是自己修改的，当然是可以看到的。

接着在事务A执行的过程中，突然开启了一个事务C，这个事务的id是78，然后它更新了那行数据的值为C，还提交了。这个时候事务A再去查询，会发现当前数据的trx_id=78，大于了自己的ReadView中的max_trx_id(60)，说明是这个事务A开启之后，然后有一个事务更新了数据，自己当然是不能看到的。如下图：

readView2.jpg

此时就会顺着undo log多版本链条往下找，自然先找到自己之前修改的那个版本，因为那个trx_id=45跟自己的ReadView里的creator_trx_id是一样的，所以此时直接读取自己之前修改的那个版本就行了。

RC隔离级别的实现

如何基于ReadView机制来实现RC隔离级别呢？其实这里的一个非常核心的要点在于，当你一个事务设置它处于RC隔离级别的时候，它是每次发起查询都重新生成一个ReadView的。

举个例子：假设数据库里有一行数据，是事务id=50的一个事务之前就插入进去的，然后现在活跃着两个事务，一个是事务A（id=60），一个是事务B（id=70），事务B发起了一次update操作，把这条数据的值改为了B，此时该行数据的trx_id=70，同时会生成一条undo log，由roll_pointer来指向。

rr2.jpg

这个时候，事务A发起一次查询操作，就会生成一个ReadView，此时ReadView里的min_trx_id=60，max_trx_id=71，creator_trx_id=60，此时发现当前这条数据的trx_id=70，也就是说，属于ReadView的事务id范围之间，说明是它生成ReadView之前就有这个活跃的事务，是这个事务修改了这条数据的值，但是此时这个事务B还没提交，所以ReadView的m_ids活跃事务列表里，是有[60, 70]两个id的，所以此时根据ReadView的机制，此时事务A是无法查到事务B修改的B值。

接着就顺着undo log版本链往下找，就会找到一个原始值，发现它的trx_id=50，小于当前ReadView里的min_trx_id，说明是它生成ReadView之前，就有一个事务插入了这个值并且早就提交了，因此可以查到这个原始值。

接着，假设事务B此时就提交了，那么就说明事务B不会活跃在数据库里了，那么按照RC隔离级别的定义，事务B此时一旦提交了，说明事务A下次再查询就可以读到事务B修改过的值了。那么怎么让事务A能够读取到提交的事务B修改过的值呢？很简单，就是让事务A下次发起查询，再次生成一个ReadView，此时数据库内活跃的事务只有事务A了，m_ids这个活跃事务列表里，只有一个60了。此时事务A再次基于这个ReadView去查询，会发现这条数据的trx_id=70，虽然在ReadView的min_trx_id和max_trx_id范围之间，但是此时并不在m_ids列表内，说明事务B在生成本次ReadView之前就已经提交了。那么既然在生成本次ReadView之前，事务B就已经提交了，就说明这次查询就可以查到事务B修改过的这个值了。

RR隔离级别的实现

下面我们来看一下RR隔离级别是如何实现的。首先我们还是假设有一条数据，是由事务id=50的一个事务插入的，同时有事务A和事务B在运行，事务A的id是60，事务B的id是70。此时事务A发起了一个查询，它就是第一次查询就会生成一个ReadView，此时ReadView里的creator_trx_id是60，min_trx_id是60，max_trx_id是71，m_ids是[60, 70] 。现在事务B更新了这条数据的值为B，此时会修改trx_id为70，同时生成一个undo log，而且事务B此时提交了，也就是事务B此时结束了。如下图：

rr2.jpg

这个时候ReadView中的m_ids列表还会是60和70吗？那必然是的，因为ReadView一旦生成了就不会改变了，这个时候虽然事务B已经结束了，但是事务A的ReadView里还是会有60和70两个事务id。它的意思其实就是，在你事务A开启查询的时候，事务B当时是在运行的，就是这个意思。接着此时事务A去查询这条数据的值，它会发现此时数据的trx_id是70了，70一方面是在ReadView的min_trx_id和max_trx_id的范围区间内，同时还在m_ids列表中。说明起码是事务A开启查询的时候，id为70的这个事务B还在运行，然后由这个事务B更新了这条数据，所以此时事务A是不能查询到事务B更新的这个值的，因此这个时候继续顺着指针往历史版本链条上去找。

接着事务A顺着指针找到下面一条数据，trx_id为50，是小于ReadView的min_trx_id的，说明在它开启查询之前，就已经提交了这个事务了，所以事务A是可以查询到这个值的，此时事务A查到的是原始值。这样就避免了不可重复读的问题。

假设现在事务A先用select * from X where id > 10来查询，此时可能查到的就是一条数据，而且读到的是这条数据的原始值的那个版本，至于原因上面都说过了。现在有一个事务C插入了一条数据，然后提交了，如下图所示：

rr4.jpg

最后，所谓的MVCC机制，也就是multi-version concurrent control多版本并发控制机制，就是基于undo log多版本链条+ReadView机制来做的。这就是数据库的隔离机制以及底层原理。