Read Committed隔离级别是如何基于ReadView机制实现的？

RC隔离级别，实际上意思就是说事务运行期间，只要别的事务修改数据还提交了，就是可以读到人家修改的数据的，所以是会发生不可重复读的问题，包括幻读的问题，都会有的。

所谓的ReadView机制，是基于undo log版本链条实现的一套读视图机制，意思就是说事务生成一个ReadView，然后呢，如果是事务自己更新的数据，自己是可以读到的，或者是在生成ReadView之前提交的事务修改的值，也是可以读取到的。

但是如果生成ReadView的时候，就已经活跃的事务，在生成ReadView之后修改了数据，接着提交了，此时是读不到的，或者生成ReadView以后再开启的事务修改了数据，还提交了，此时也是读不到的。

上面的那套机制，实际上就是ReadView机制的一个原理。

如何基于ReadView机制来实现RC隔离级别呢？

其实这里的一个非常核心的要点在于，当一个事务设置它处于RC隔离级别的时候，它是每次发起查询，都重新生成一个ReadView！

首先假设数据库里有一行数据，是事务id=50的一个事务之前就插入进去的，然后现在呢，活跃着两个事务，一个是事务A（id=60），一个是事务B（id=70），此时如下图所示：

现在的情况就是，事务B发起了一次update操作，更新了这条数据，把这条数据的值修改为了值B，所以此时数据的trx_id会变为事务B的id=70，同时会生成一条undo log，由roll_pointer来指向，看下图：

这个时候，事务A要发起一次查询操作，此时它一发起查询操作，就会生成一个ReadView，此时ReadView里的min_trx_id=60，max_trx_id=71，creator_trx_id=60，此时如下图所示：
这个时候事务A发起查询，发现当前这条数据的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不会活跃于数据库里了，是不是？事务B现在提交了。那么按照RC隔离级别的定义，事务B此时一旦提交了，说明事务A下次再查询，就可以读到事务B修改过的值了，因为事务B提交了。

那么到底怎么让事务A能够读到提交的事务B修改过的值呢？

很简单，就是让事务A下次发起查询，再次生成一个ReadView。此时再次生成ReadView，数据库内活跃的事务只有事务A了，因此min_trx_id是60，mac_trx_id是71，但是m_ids这个活跃事务列表里，只会有一个60了，事务B的id=70不会出现在m_ids活跃事务列表里了，如下图：

此时事务A再次基于这个ReadView去查询，会发现这条数据的trx_id=70，虽然在ReadView的min_trx_id和max_trx_id范围之间，但是此时并不在m_ids列表内，说明事务B在生成本次ReadView之前就已经提交了。

那么既然在生成本次ReadView之前，事务B就已经提交了，就说明这次查询就可以查到事务B修改过的这个值了，此时事务A就会查到值B，如下图所示：

RC隔离级别如何实现的，关键点在于每次查询都生成新的ReadView，那么如果在这次查询之前，有事务修改了数据还提交了，这次查询生成的ReadView里，那个m_ids列表当然不包含这个已经提交的事务了，既然不包含已经提交的事务了，那么当然可以读到修改过的值了。