个人理解篇，不一定对，应付面试的时候看的
MVCC(Multi-Version Concurrency Control)全称多版本并发控制，主要用在隔离模式下的提交读、可重复读模式下，依赖于readview和undolog链
一、readview
1、结构
|----------------|--------------------|
| 字段 | 备注 |
| m_ids | 活跃事务id集合 |
| min_trx_id | 活跃事务id集合中最小事务id |
| max_trx_id | 当前分配给新事务的最大事务id+1 |
| creator_trx_id | 生成readview时,当前事务id |
2、举例
现在系统中开启了事务A、B、C，对应的trx_id分别是1、2、3
此时有个新事务的读操作时，会产生如下readview
|----------------|-------|
| m_ids | 1,2,3 |
| min_trx_id | 1 |
| max_trx_id | 5 |
| creator_trx_id | 4 |
二、undolog链
1、结构
|-------------|---------------------------------|
| 字段 | 备注 |
| trx_id | 事务id |
| roll_point | 上一事务指针，指向上一个undolog节点 |
| key | 操作行记录的主键id |
| type | 执行类型（update、insert、delete） |
| commonvalue | 具体的值，没搞清楚具体是什么，但是新值、旧值、更新逻辑应该都有 |
2、举例
现在系统中开启了事务A、B、C，对应的trx_id分别是1、2、3
此时有个新事务的读操作时，会读取一下undolog链如下
三、操作
1、新事物发起读操作时产生readview,然后从undolog链开始查找并进行如下判断逻辑
if（trx_id == creator_trx_id）访问的是自己的事务，允许访问
if（trx_id < min_trx_id）访问的是已经提交的事务，允许访问
if（trx_id >= max_trx_id）访问的是在生成readview之后的事务，不允许访问
if（min_trx_id <= trx_id < max_trx_id）访问的是活跃中未提交的事务，不允许访问
ps:
1、关于undo链中的举例结构图，其实可以看出，默认在 trx_id=1的条目之前还会有trx_id=0的条目 这个条目是在生成readview时最新的提交数据，在trx_id=3后如果有新事务的话，其实也还有指向trx_id=3的事务，这只是个片段，具体的判断阶段会在这图中这一部分判断的比较集中。
2、关于trx_id=1指向的上一个已提交事务的undolog条目，由mysql来采取一些算法来判断是否存在，一般在被引用的时候都是存在的，不必担心找不到已提交的undolog条目
3、每个undolog条目都是某个表的某一行的数据，如果update修改了10条记录，那么会产生10个undolog条目，同时每个undolog链其实只是某一行的版本变化
四、关于
1、RC和RR区别
mvcc可以在RC(读已提交)和RR(可重复读)中，区别就是RC模式下，每次读都会产生readview，而在可重复读模式下，事务结束之前都是复用事务开始后的第一次读产生的readview
2、RR幻读问题
RR中其实没有完全解决幻读问题，如下场景
2.1表Subject：
场景一：
|-----------------------------------------------------------------------------------|-------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
| 事务A | 事务B | 事务B查询结果 |
| start TRANSACTION; | start TRANSACTION; | |
| | select * from Subject where difficultly = "困难"; | 
|
| insert into `Subject`(difficultly,type,language) value ('困难','英语','C'); commit; | | |
| | select * from Subject where difficultly = "困难" for update; | 
|
| | select * from Subject where difficultly = "困难" | |
可以看到第四步的当前读会出现幻读，而第五步的快照读仍然正常
场景二：
|-----------------------------------------------------------------------------------|-------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
| 事务A | 事务B | 事务B查询结果 |
| start TRANSACTION; | start TRANSACTION; | |
| | select * from Subject where difficultly = "困难" for update; | |
| insert into `Subject`(difficultly,type,language) value ('困难','英语','C'); commit; | | |
| | select * from Subject where difficultly = "困难" for update; | |
| | select * from Subject where difficultly = "困难" | |
第三步中事务A在执行插入时会一直无法执行完成，直到事务B中commit后才会执行完成
场景一和场景二区别：
场景一中事务B在事务A插入新数据和提交后执行的当前读，而场景二中事务B在事务A插入新数据和提交前执行的当前读，mysql通过mvcc和临键锁会锁定当前读，这样事务A再插入就插入不了新数据了，就解决了幻读，而场景一是在使用临键锁之前提交的，当前读读的是最新数据，所以会出现幻读