MySQL中MVCC机制相比HBase来说要复杂的多，涉及的数据结构也比较复杂。为了解释的比较清晰，以一个栗子为模版进行解释。比如当前有一行记录如下图所示：
前面四列是该行记录的实际列值，需要重点关注的是DB_TRX_ID和DB_ROLL_PTR两个隐藏列（对用户不可见）。其中DB_TRX_ID表示修改该行事务的事务ID，而DB_ROLL_PTR表示指向该行回滚段的指针，该行记录上所有版本数据，在undo中都通过链表形式组织，该值实际指向undo中该行的历史记录链表。
现在假设有一个事务trx2修改了该行数据，该行记录就会变为下图形式，DB_TRX_ID为最近修改该行事务的事务ID(trx2)，DB_ROLL_PTR指向undo历史纪录链表：
了解了MySQL行记录之后，再来看看事务的基本结构，下图是MySQL的事务数据结构，上文我们提到过。事务在开启之后会创建一个数据结构存储事务相关信息、锁信息、undo log以及非常重要的read_view信息。
read_view保存了当前事务开启时整个MySQL中所有活跃事务列表，如下图所示，在当前事务开启的时候，系统中活跃的事务有trx4、trx6、trx7以及trx10。另外，up_trx_id表示当前事务启动时，当前事务链表中最小的事务ID；low_trx_id表示当前事务启动时，当前事务链表中最大的事务ID。
read_view是实现MVCC的一个关键点，它用来判断记录的哪个版本对当前事务可见。如果当前事务要读取某行记录，该行记录的版本号（事务ID）为trxid，那么：
1. 如果trxid < up_trx_id，说明该行记录所在的事务已经在当前事务创建之前就提交了，所以该行记录对当前事务可见。
2. 如果trxid > low_trx_id，说明该行事务所在的事务是在当前事务创建之后才开启，所以该行记录对当前事务不可见。
3. 如果up_trx_id < trxid < low_trx_id， 那么表明该行记录所在事务在本次新事务创建的时候处于活动状态。从up_trx_id到low_trx_id进行遍历，如果trxid等于他们之中的某个事务id的话，那么不可见，否则可见。
以下面行记录为例，该行记录存在多个版本（trx2、trx5、trx7以及trx12），其中trx12是最新版本。看看该行记录中哪个版本对当前事务可见。
1. 该行记录的最新版本为trx12，与当前事务read_view进行对比发现，trx12大于当前活跃事务列表中的最大事务trx10，表示trx12是在当前事务创建之后才开启的，因此不可见。
2. 再查看该行记录的第二个最新版本为trx7，与当前事务read_view对比发现，trx7介于当前活跃事务列表最小事务ID和最大事务ID之间，表明该行记录所在事务在当前事务创建的时候处于活动状态，在活跃列表中遍历发现trx7确实存在，说明该事务还没有提交，所以对当前事务不可见。
3. 继续查看该记录的第三个最新版本trx5，也介于当前活跃事务列表最小事务ID和最大事务ID之间，表明该行记录所在事务在当前事务创建的时候处于活动状态，但遍历发现该版本并不在活跃事务列表中，说明trx5对应事务已经提交（注：事务提交时间与事务编号没有任何关联，有可能事务编号大的事务先提交，事务编号小的事务后提交），因此trx5版本行记录对当前事务可见，直接返回。
上文介绍了MySQL中MVCC技术实现机制，但要明白RC隔离级别下事务可见性，还需要get一个核心点：RC隔离级别下的事务在每次执行select时都会生成一个最新的read_view代替原有的read_view。
如上图所示，左侧为1号事务，在不同时间点对id=1的记录分别查询了三次。右侧为2号事务，对id=1的记录进行了更新。更新前该记录只有一个版本，更新好变成了两个版本。
1号事务在RC隔离级别下每次执行select请求都会生成一个最新的read_view，前两次查询生成的全局事务活跃列表中包含trx2，因此根据MVCC规定查到的记录为老版本；最后一次查询的时间点位于2号事务提交之后，因此生成的全局活跃事务列表中不包含trx2，此时在根据MVCC规定查到的记录就是最新版本记录。
Repeatable Read（技术解读：写写并发使用X锁，读写并发使用MVCC避免不可重复读；当前读使用Gap锁避免幻读）