前言
早上上班途中，趁着坐地铁的功夫翻了翻高性能MySQL这本书，准备回顾一下MVCC这块的知识点，因为书中对MVCC的讲解不是很多，于是我很快便看完了这一段落，但是文章末尾有一段话引起了我的思考。
MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容，因为READ UNCOMMITED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。
摘抄——《高性能mysql第三版》
之前我对RR与RC的区别不是很清晰，自从了解了MVCC后，因为MVCC机制解决了不可重复读的问题，于是我便认为RR=RC+MVCC。但是书中既然说MVCC可以工作在这两个级别下，那么很显然，我的理解是存在着一些问题的。
思考逻辑：既然MVCC可以工作在RC级别下，那么RC便可以通过MVCC实现重复读，这样一来RR便失去了意义。抱着存在即为合理的态度，所以觉得自己的理解应该是有问题。
MVCC在InnoDB中的实现
然后我了解到InnoDB为数据库中的每一行添加了三个隐藏字段：DB_TRX_ID(事务版本号)、DB_ROLL_PTR(回滚指针)、DB_ROW_ID(隐藏ID)。
-
DB_TRX_ID：记录了创建/更新这条数据的事务版本号（版本号会递增）。 -
DB_ROLL_PTR：记录了一个指向undo log中历史版本的数据指针。（用来支持回滚操作） -
DB_ROW_ID：一个自增的隐藏行ID。
InnoDB基于事务版本号、回滚指针这两个字段，可以在undo log中形成一个单向链表，最新版本的数据放在链表头部，历史数据通过DB_ROLL_PTR指针进行关联。如下图所示
有了这种结构的数据后，InnoDB可以很方便的管理多个版本的数据，也为MVCC的实现打下来基础。
MVCC解决了哪些问题？
接下来我们来了解一下MVCC在InnoDB中具体的实现逻辑是怎样的，以及MVCC解决了哪些问题。
首先，InnoDB在事务开启后执行第一个查询时，会创建一个快照（下文称之为ReadView），这个ReadView包含了以下信息
-
m_ids: 活动事务id列表（活动事务指的是已经开始、尚未提交/回滚的事务） -
min_trx_id: 最小活动事务id -
max_trx_id:最大活动事务id -
creator_trx_id:当前事务id
紧接着InnoDB会通过查询语句定位到最新版本的数据行，并根据以下规则获取到可以访问的数据版本。
-
如果被访问版本的trx_id，与readview中的creator_trx_id值相同，表明当前事务在访问自己修改过的记录，直接返回该版本的数据；
-
如果被访问版本的trx_id，小于readview中的min_trx_id值，表明生成该版本的事务在当前事务生成readview前已经提交，直接返回该版本的数据；
-
如果被访问版本的trx_id，大于或等于readview中的max_trx_id值，表明生成该版本的事务在当前事务生成readview后才开启，此时该版本不可以被当前事务访问，需要通过隐藏的回滚指针从undo log中读取历史版本；
-
如果被访问版本的trx_id，在readview的min_trx_id和max_trx_id之间，则需要判断trx_id值是否在m_ids列表中？
-
-
如果在：说明readview创建时，创建该版本数据的事务还未提交，因此需要通过回滚指针读取历史版本并返回。 -
如果不在：说明readview创建时，创建该版本数据的事务已经提交，所以直接返回该版本的数据；
可重复读隔离级别下，ReadView只会在第一次查询时创建，同一个事务中后续所有的查询共用一个ReadView，由此便解决了不可重复读的问题。
读已提交隔离级别下，每次查询都会创建一个新的ReadView。新建的ReadView会更新creator_trx_id以外的其余字段，因此不可重复读现象依然存在。但是由于ReadView可以判断出修改此数据的事务是否已经提交，因此可以避免脏读的出现。
其次，从上述MVCC实现逻辑中可以发现，没有任何加锁、获取锁的操作，因此MVCC读操作不会因为等待锁而阻塞（也就是常说的非阻塞读）。
总结
MVCC可以解决脏读、不可重复读，并且实现了非阻塞读的功能。
读已提交隔离级别：每次读操作都会设置和读取自己的新快照（ReadView）。
可重复读隔离级别：同一个事务共用第一次查询时建立的快照（ReadView）。
当前读与快照读
最后扩展一个延伸的知识点，其实Mysql中的读操作可以分为两大类：快照读与当前读。
快照读是指通过MVCC实现的非阻塞读，常见的快照读操作如下：
-
select xxx from xxx
当前读也叫加锁读，每次读取数据都是读取数据的最新版本，并且会对其进行加锁。常见的当前读操作如下
-
select xxx from xxx lock in share mode (共享锁/读锁) -
select xxx from xxx for update （排它锁/写锁） -
update 、delete、insert
为什么要区分这两种读操作呢？因为MVCC并不能解决幻读的问题。即使是在可重复读级别，通过当前读依然会出现幻读问题。此问题最终是通过间隙锁来解决的。
原文始发于微信公众号（敲得码黛）：深入了解Mysql的MVCC机制
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/28410.html
