MVCC
MVCC 是多版本并发控制方法，用来解决读和写之间的冲突，比如脏读、不可重复读问题，MVCC主要针对读操作做限制，保证每次读取到的数据都是本次读取之前的已经提交事务所修改的。
概述
当一个事务要对数据库中的数据进行select查找时，MVCC 会为该事务创建一个read view数据快照，查询语句会把在read view产生之前没提交的修改以及在read view产生之后才提交的事务对应的修改屏蔽掉，最终只能读取到这个read view产生之前其它事务所提交的更改。换句话说，读操作读取的是旧版本数据（也可能是最新的），而写操作是针对最新的版本记录，所以能解决读-写冲突问题。
具体实现
它基于数据行的隐藏字段、undo log版本链、read view实现：
数据隐藏字段：最后修改事务id、回滚记录指针
undo log 版本链：用于记录某行数据的多个版本的数据，通过一个回滚指针字段链接起来
read view : 每个事务的读取时会产生一个read view，记录了一些列的事务id，具体有如下四个字段：
- creator_trx_id，创建当前Read View的事务ID。
- trx_ids，表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
- min_limit_trx_id，活跃的事务中最小的事务id。
- max_trx_id，表示生成ReadView时系统中应该分配给下一个事务的id值。low_limit_id是系统最大的事务id值，这里要注意是系统中的所有事务id，不仅包含正在活跃的事务id、还包含之前已提交的事务id。
注意:
- 只有在对表中的记录做改动时(执行INSERT、DELETE、UPDATE这些语句时)才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为0。
- low_limit_id并不是活跃事务列表trx_ids中的最大值，而是所有事务id中最大的+1，这里的所有事务包括活跃的、已提交的。比如，现在有id为1，2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时，trx_ids就包括1和2，up_limit_id的值就是1,low_limit_id的值就是4。
MVCC工作流程
- 某个事务执行select查找时，首先根据数据行的某个字段获取事务自己的版本号，也就是事务ID;
- 然后创建ReadView;
- 查询得到最新数据，然后与ReadView中的事务版本号按照一定规则进行比较;
- 如果不符合ReadView规则，就需要从Undo Log 中获取历史快照;
- 一直往前查找，直到返回符合规则的数据。
read view是怎么去找到当前read view创建之前已经提交修改的最新数据的，具体规则是什么？
先根据数据行记录的回滚指针，在undo日志中找到最新一条记录，找到其对应的事务id，然后做四轮对比：
- 对比最新记录的事务id和当前read view的事务id，如果相同，则说明最新的数据就是当前事务修改的，可以直接读。（等于当前id，代表是自己改的，则可读）
- 对比最新记录的事务id和当前read view的记录的活跃事务id最小值，看看是不是当前记录是不是read view创建之前就已经提交完的，如果是，则可以直接读。（小于最小活跃事务id，代表之前提交的修改，则可读）
- 对比最新记录的事务id和当前read view的记录的最大事务id，看看当前记录是不是read view创建之后才有的，如果是就不读。（大于最大事务id，代表后面才提交的修改，不可读）
- 对比最新记录的事务id是不是存在于当前活跃事务id列表当中，如果存在，则说明是未提交的数据，不能读取；如果不存在，则可读。（在活跃事务列表里，代表未提交的修改，可读）
这四轮对比完之后，如果都显示不能读，则找到undo日志的下一跳数据，继续四轮对比。知道找到某条可读的记录。
假设事务5创建read view时，系统中有8个事务，对应查找情况如下：
疑问：其实整个流程就是把那些活跃事务（未提交）造成的修改排除掉，然后再判断下当前事务是创建read view之前提交的还是创建read view之后提交的，那为什么要在最后一步才去判断事务id是否在活跃id列表中？
自我理解：因为判断某个id是否在活跃事务id列表里，需要一次遍历操作，放在第一步去做的话每次都要遍历，速度很慢；其实可以先把其它情况处理掉（不需要遍历），当别的情况都不满足时，最后再考虑是否在活跃id列表中，以此提高查找效率。
事务隔离级别与MVCC
四个事务隔离级别与MVCC的关系？
首先，最低的读未提交和串行化没有用到MVCC机制，而读已提交和可重复度用到了MVCC去解决读写冲突中的脏读取和不可重复读的问题。
读已提交隔离级别中，MVCC怎么解决脏读的？
同一个事务中每次读取时创建一个read view，根据read view中记录的事务id去undo log中把其它未提交事务的记录个过滤掉，只会读取已提交事务所造成的修改。
问题：因为每次查询都会创建一个read view，所以两次查询之间，如果其它事务对数据进行修改，这时对第二次查询产生的read view的视角下，刚刚的修改是可见的，所以这就有了不可重复读的问题。
可重复读隔离级别中，MVCC怎么解决不可重复读？保证可重复读？
对于同一个事务中对同一条数据的多次读取，复用之前的read view，也就是只有在首次读取数据时才会产生read view，这就避免了出现在一个事务中的多次读取结果不一样的情况。
总结MVCC机制
MVCC 是多版本并发控制方法，用来解决读和写之间的冲突，比如脏读、不可重复读问题，MVCC主要针对读操作做限制，保证每次读取到的数据都是本次读取之前的已经提交事务所修改的。
它具体实现依赖于数据行隐藏字段、undo log版本链和read view。
具体过程：在某个事务执行读操作时，可以通过数据行的隐藏列去找到undo日志中的历史版本记录，每个历史版本记录里面都记录了事务id，然后会读操作会创建一个read view视图，里面包含了一些事务id的数据，然后通过对比read view里面的事务id数据和undo版本链中的事务id数据，就可以找到read view创建之前所提交的数据。
追问：read view具体记录了哪些数据，具体怎么去和undo log中记录的id对比，最后找到想要的数据的？
read view视图里面记录了当前事务id、当前未提交事务（活跃事务）id列表、当前未提交事务id列表的最小值、当前最大事务id。先找到undo log第一条数据，对比事务id和read view当前事务id是否一样。。，对比事务id是不是小于最小活跃事务id。。。，然后对比事务id是不是大于最大事务id。。。，最后判断事务id是不是在活跃事务id列表里面。。