MVCC，即多版本并发控制(Multi-Version Concurrency Control)指的是，通过版本链维护一个数据的多个版本，使得读写操作没有冲突，可保证不同事务读写、写读操作并发执行，提高系统性能。
实际上，innodb中“读已提交”和“可重复读”这两种隔离级别的事务在查询数据时访问版本链的过程，是基于这套原理。本文将总结MVCC机制底层原理，并解释它是如何解决“脏读”和“不可重复读”问题的。
感觉现在每总结一个知识点，总是会引出一堆相关知识，学习真的是永无止境~。首先介绍一下几种并发事务问题，和四种隔离级别，这与后文原理介绍密不可分。而且，毕竟都是面试高频考点，尊重一下。
并发事务带来的问题
脏读：表示一个事务读到另一个事务未提交的数据。若另一个事务回滚，那本事务读到的数据跟数据库中的不一致；
可重复读：表示一个事务读到另一个事务已提交的数据。本事务在另一个事务提交前和提交后读到的数据不一致；
幻读：其它事务插入数据的前后，当前事务两次读取的数据不一致；
丢弃修改：两个事务先同时读取一个数据，读到一样的数据，然后事务一先修改，事务二再修改，事务一的修改被丢弃。
事务的四种隔离级别
读未提交 READ-UNCOMMITTED：一个事务能读到其它事务未提交的数据，即脏读。也会出现不可重复读和幻读。
读已提交 READ-COMMITTED：一个事务只能读到其它事务已提交的数据，不会出现脏读，但是有幻读和不可重复读
其它事务提交修改语句的前后，当前事务两次读取的数据可能不一样。不称之为，不可重复读；
其它事务提交插入语句前后，当前事务可能会把新插入的数据也读出来。称之为，幻读；
可重复读 REPEATABLE-READ(MySQL默认使用的隔离级别)：对一个数据读取多次记录是相同的。sql标准里，REPEATABLE-READ禁止了脏读和不可重复读，可能会有“幻读”。但是MySQL中REPEATABLE-READ也禁止了幻读
串行化 SERIALIZABLE：前三种都允许读-读、读-写、写-读的并发操作，但SERIALIZABLE中不允许读-写、写-读的并发操作，而是串行的，不会出现各种问题
innodb中采用了next-key-lock锁算法避免了幻读，使得“可重复读”级别也达到了“串行化”级别的效果
MVCC机制
我们先设定一个场景：
假设数据库表中存在一条记录row_old，这时事务A和事务B同时begin，事务A将该记录修改为了row_new，事务B读取行记录，事务A提交，事务B再次读取这条行记录。
本文中将使用该场景来分析“脏读”和“不可重复读”现象。
若事务B在A提交前读到row_new，即出现“脏读”现象；若事务B在A提交后读到row_new，即出现“不可重复读”现象。
但是，正常情况是，无论事务A是否提交，事务B读取该条记录，都只能读出row_old。
什么方法可以达到这种效果呢？可以很直观地想到，将事务A修改后的版本存起来。那么又有一系列问题，如何存，用什么结构来存？版本链便是为此而引入的。
版本链
版本链，实际上就是一条存储多个版本行记录的链表。数据库中的每一行数据都对应一个版本链。链表中每一个结点代表一个行记录。行记录中有两个重要的隐藏字段：
trx_id：记录修改成当前版本的事务编号；
roll_pointer：指向上一个版本的指针，即回滚指针。
版本链的最底层即为数据表中最原始的行记录，上层存储各个事务修改后的行记录，逐个用回滚指针相连接。版本链示意图如下所示：
还有一个问题，版本链是存储在哪的？没错，我们熟悉的undo log回滚日志就是用来存储版本链的 。
一致性视图
如果当前事务修改一条记录，这条更新过的记录被记录到版本链中，对于当前事务而言，由于自身事务id和版本链中最新一条行记录的trx_id相匹配，所以可以将其读取出来。但是对于其它事务而言，是不希望能读出这条记录的，而是希望它能顺着版本链，找出自己需要的版本的行记录。
那么如何找到正确的版本？这里涉及到一个快照机制。事务在执行select语句时，会生成一个一致性视图：read-view，相当于一个快照，记录正在活跃的事务的编号。
read-view里面包含一个数组，m_ids，该数组记录（产生快照的这一时刻）版本链中未提交的每个版本的trx_id组成的序列。同时，read-view还会记录一个最大已创建事务id，即 max_id，以及数组中最小id即 min_id。查询版本链时，会将行记录中的trx_id与read-view中的max_id、min_id、m_ids[]等进行比对。依据如下版本比对规则来进行比对。
版本链比对规则
如果trx_id小于min_id，说明该版本是已提交事务生成的，数据可见；
如果trx_id大于max_id，说明该版本是将来启动的事务生成的，数据不可见；
如果min_id<=trx_id<=max_id，就包括两种情况：
trx_id在m_ids数组中：表示这个版本是未提交事务生成的，数据不可见，本事务可见；
trx_id不在m_ids数组中：表示这个版本是已提交事务生成的，数据可见。
补充：删除的原理：
删除可以认为是update的特殊情况。假如要删除一行记录，会将版本链上最新一条记录复制一份，将行格式头信息中(record header)里面的(deleted flag)标志位置为true，表示当前记录已被删除。若顺着版本链访问到这条记录，(deleted flag)标志位为true，表示记录已删除，不返回数据。
相关分析
“脏读”分析
让我们再回到前文提到的场景：事务A将行记录row_old修改为了row_new，未提交时，row_new行记录已经加入到了版本链，并且记录了事务A的id。此时事务B开始查询，生成快照read-view，其中的m_ids记录了未提交版本的trx_id，包括row_new的id。当查询到row_new时，其trx_id在m_ids数组中，根据版本链比对规则，其对B事务不可见，因此继续向下查找，直到找出row_old。
综上所述，read-view快照机制加上版本链匹配规则，可以杜绝“脏读”现象。
“读已提交”和“可重复读”区别
根据上文的分析，我们对MVCC机制有了一个清晰的了解。在“读已提交”隔离级别就是基于这个原理来解决“脏读”问题的。而“可重复读”隔离级别却与之不尽相同，差别如下：
读已提交：每次select时都会生成一个readView;
可重复读：只在事务的第一次select操作前生成一个readView，之后的查询都重复使用这个readView。
“不可重复读”分析
再次回到上文中提到的情景，假设事务A修改将row_old修改为row_new，未提交时，事务B开始执行select，生成read-view，这时事务A进行提交，然后事务B再次select，这时依然沿用上一次的read-view，row_new的id依然是记录在m_ids数组中的，所以事务B只能读取到row_old，两次读取都只能读出row_old。
这里我希望再补充一种情况：B事务尚未提交结束时，再开启一个事务C，修改row_new为row_new_c，并提交，这时版本链中新增一个row_new_c结点，记录C的id。事务B再次select，依然只能读取到row_old。因为在版本链中遍历至row_new_c时，会触发“版本对比规则”的第二条，该条记录对事务B不可见，因此继续向下查找直到找出row_old。
所以，综上所述，无论版本链发生何种改变，只要在单次事务中read-view固定不变，读取到的数据一定是维持在同一个版本。在“可重复读”级别中，就是通过沿用第一次read-view快照的方法，解决了“不可重复读”问题。
