1. 多个undo log形成的链表

InnoDB存储引擎中，它的聚簇索引记录中都包含两个必要的隐藏列，分别是：

trx_id：事务Id，每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id
赋值给trx_id
隐藏列。
roll_pointer：回滚指针，每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo log
中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

每个事务都会修改一组Undo Record，这些Undo Record首位相连就组成了这个事务的Undo Log。同一个Record被不同的事务修改，会产生不同的历史版本，这些历史版本又通过Rollptr串成一个链表，供MVCC使用：

MVCC原理.png

同时可以看出：Insert类型的Undo Record中记录了对应的主键值：id=1，而Update类型的Undo Record中还记录了对应的历史版本的生成事务Trx_id，以及被修改的field a的历史值。

2. MVCC版本控制

多版本的目的是为了避免写事务和读事务的互相等待，那么每个读事务都需要在不对Record加锁的情况下，找到对应的应该看到的历史版本。

InnoDB的做法是（RR隔离级别）：

在事务第一次读取的时候（select）获取一份ReadView，并一直持有；
在事务第一次DML语句（Insert、update、delete）时，为该事务分配全局的事务id；

场景1：事务开始前：id=1的trx_id为10

session1	session2	session3	session4
begin;	begin;	begin;	begin;
update id=10;(trx_id=11)
	update id=1;(trx_id=12)
	commit;
update id=1;(trx_id=11)
		select id=1;(生成ReadView)
commit;
			update id=1;(trx_id=13)
		select id=1;(结论？)

2.1 基础概念

ReadView可以理解为数据库中某一个时刻所有未提交事务的快照。ReadView有如下几个重要的参数：

m_ids：表示生成ReadView时，当前系统正在活跃的写事务Id列表（未提交的事务）；
min_trx_id：表示生成ReadView时，当前系统中活跃的写事务的最小事务Id；
max_trx_id：表示生成ReadView时，当前时间戳InnoDB将在下一次分配的事务Id；
creator_trx_id：当前事务Id；

判断逻辑：

如果被访问版本的trx_id等于creator_trx_id，表示当前事务在访问自己修改的记录，所以该版本可以被当前事务访问；
如果被访问版本trx_id属性值小于ReadView的最小事务Id，表示该版本的事务在生成ReadView前已经提交，所以该版本可以被当前事务访问；
如果被访问版本trx_id属性值大于等于ReadView的最大事务Id，表示该版本的事务在生成ReadView后才活跃状态，所以该版本不可以被当前事务访问；
如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间，那么就需要判断：
3.1 trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；
3.2 trx_id如果不在，说明创建ReadView时生成该版本的事务已经提交，该版本可以被访问。

2.2 场景1分析

session3执行时：

活跃事务列表m_id：[11]；
活跃的最小-最大事务Id：[11,13]；
当前事务Id，因为只是读事务，未分配；

在session3生成ReadView时，多个事务产生的多个undo log被roll_pointer串联起来的链表简化图如下：

mvcc版本链.png

session3执行select id=1语句时，

查询到被访问记录的trx_id=11，在最大-最小事务Id之间[11,13]，且trx_id在m_ids[11]中，该版本不能被访问；
那么mvcc版本链中查询到trx_id=12，在min_trx_id和max_trx_id之间[11,13]，但是trx_id不在m_ids[12]中，那么该版本可以被访问。

session4执行时：

mvcc版本链.png

对，undo log是在update开始时执行时就生成的，而不是在commit后才生成undo log。

session3第二次执行select id=1语句时：

查询到被访问记录的trx_id=13，等于max_trx_id，说明是在ReadView后才开启的，不能访问该版本；
那么mvcc版本链中查询到被访问记录的trx_id=11，在最大-最小事务Id之间[11,13]，且trx_id在m_ids[11]中，该版本不能被访问；
那么mvcc版本链中查询到trx_id=12，在min_trx_id和max_trx_id之间[11,13]，但是trx_id不在m_ids[12]中，那么该版本可以被访问。

3. MVCC为什么不能解决幻读

3.1 场景2

session1	session2
begin;	begin;
	insert into test(id,xid) values(2,2) ;(trx_id=10)
	commit;
select * from test where id=2;(开启ReadView)
commit;

id=2的undo log形成的版本链：

image.png

活跃id列表m_ids[]
[min_trx_id,max_trx_id]为[11,12)
被访问的id=1中trx_id=10，小于min_trx_id故可以被访问到。

因此出现了幻读；

3.3 场景3

session1	session2
begin;	begin;
select * from test;(开启ReadView)
	insert into test(id,xid) values(3,3) ;(trx_id=14)
	commit;
select * from test where id =3;（第一次查询，null）
update test set xid=30 where id=3 ;(trx_id=15)
select * from test where id =3;（第二次查询，not null）
commit;

开启ReadView时：

活跃id列表m_ids[]
[min_trx_id,max_trx_id]为[10,12)
session1的第一次查询时，id=3的trx_id=14大于max_trx_id，说明是生成ReadView后才生成的记录，不可以访问到；
session1的update操作，session1事务生成trx_id=15，因为更新id=3，所以id=3的Record也是trx_id=15；
session1的第二次查询时，id=3的trx_id=15等于creator_trx_id（自己的事务id），可以被访问到；

因此再次出现了幻读。

好文阅读

庖丁解InnoDB之Undo LOG

【精】使用各种场景彻底明白mysql的MVCC原理