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

1. 多个undo log形成的链表

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

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

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

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

2. MVCC版本控制

多版本的目的是为了避免写事务和读事务的互相等待，那么每个读事务都需要在不对Record加锁的情况下，找到对应的应该看到的历史版本。在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

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有如下几个重要的参数：

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

判断逻辑：

1. 如果被访问版本的trx_id等于creator_trx_id，表示当前事务在访问自己修改的记录，所以该版本可以被当前事务访问；
2. 如果被访问版本trx_id属性值小于ReadView的最小事务Id，表示该版本的事务在生成ReadView前已经提交，所以该版本可以被当前事务访问；
3. 如果被访问版本trx_id属性值大于等于ReadView的最大事务Id，表示该版本的事务在生成ReadView后才活跃状态，所以该版本不可以被当前事务访问；
4. 如果被访问版本的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执行时：

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

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

session3执行select id=1语句时，

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

session4执行时：

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

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

1. 查询到被访问记录的trx_id=13，等于max_trx_id，说明是在ReadView后才开启的，不能访问该版本；
2. 那么mvcc版本链中查询到被访问记录的trx_id=11，在最大-最小事务Id之间[11,13]，且trx_id在m_ids[11]中，该版本不能被访问；
3. 那么mvcc版本链中查询到trx_id=12，在min_trx_id和max_trx_id之间[11,13]，但是trx_id不在m_ids[12]中，那么该版本可以被访问。在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

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形成的版本链：

1. 活跃id列表m_ids[]
2. [min_trx_id,max_trx_id]为[11,12)
3. 被访问的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时：

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

因此再次出现了幻读。

• List item