MVCC机制

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

MVCC(Multi-Version Concurrency Control)全称多版本并发控制，主要用在隔离模式下的提交读、可重复读模式下，依赖于readview和undolog链

现在系统中开启了事务A、B、C，对应的trx_id分别是1、2、3

此时有个新事务的读操作时，会产生如下readview

字段	备注
trx_id	事务id
roll_point	上一事务指针，指向上一个undolog节点
key	操作行记录的主键id
type	执行类型（update、insert、delete）
commonvalue	具体的值，没搞清楚具体是什么，但是新值、旧值、更新逻辑应该都有

现在系统中开启了事务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链其实只是某一行的版本变化

mvcc可以在RC(读已提交)和RR(可重复读)中，区别就是RC模式下，每次读都会产生readview，而在可重复读模式下，事务结束之前都是复用事务开始后的第一次读产生的readview

RR中其实没有完全解决幻读问题，如下场景

事务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 = "困难"