个人理解篇，不一定对，应付面试的时候看的

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再插入就插入不了新数据了，就解决了幻读，而场景一是在使用临键锁之前提交的，当前读读的是最新数据，所以会出现幻读