MySQL进阶突击系列(05)突击MVCC核心原理 | 左右护法ReadView视图和undoLog版本链强强联合

2024小结：在写作分享上，这里特别感谢CSDN社区提供平台，支持大家持续学习分享交流，共同进步。社区诚意满满的干货，让大家收获满满。

对我而言，珍惜每一篇投稿分享，每一篇内容字数大概6000字左右，加上画图，以及案例demo代码编写、实战，撰稿时长平均3小时左右。由于年底工作特别忙，晚上下班回家，有时候娃已经睡着了，如果娃没睡还得陪娃玩直到她睡着才有空继续写作。每天空闲时间非常少，经常一篇文章从周一写到周末才能完成。

近5个月以来投稿并不多，仅29篇。新的一年，争取有更多时间，和大家交流学习分享，包括家庭、日常、职场其他非技术性内容。

一、前言背景

二、通俗演义-MVCC多版本并发控制核心原理

2.1 解密-基于undoLog实现的数据版本链

2.2 弯弯绕绕看不懂的readView视图-一句话总结看懂

三、MVCC解决脏读、不可重复读、幻读问题demo详解

3.1 验证MVCC解决脏读、不可重复读问题【并发事务一个重复查+另一个改】

3.2 验证MVCC解决幻读、不可重复读问题【并发事务一个重复查，一个新增】

四、脏写是什么？如何解决

【公众号搜索：拉丁解牛说技术】欢迎同学们关注交流讨论。

一、前言背景

之前系列4文章说过MySQL InnoDB存储引擎，默认事务隔离级别是可重复读repeatable-read。我们可通过命令查看：SELECT @@SESSION.tx_isolation;

而且也说到，MySQL的可重复读事务隔离级别，可以解决脏读、幻读、不可重复读三大事务并发问题。当时也留了一个思考题：MySQL是如何做到的？答案是MVCC+锁。核心在于MVCC。

那MySQL如何让实现一个事务多次读，不受另一个事务的增、改、删的影响。带着这个问题，我们一步步解密MySQL的MVCC多版本并发控制核心机制。

二、通俗演义-MVCC多版本并发控制核心原理

MVCC，全称是Multi Version Concurrency Control多版本并发控制。MySQL innoDB存储引擎，在新增修改删除数据的时候，并没有真正用新数据直接更新覆盖，而是采用版本链方式去保存数据修改记录。每个读事务，对应一个版本的数据快照。每个写事务，在事务提交之前，该事务内做的任何更新操作未提交之前，其他任何事务不可见该更新。

举一个通俗的案例，也是我们日常实践的数据版本管理。比如用户信息user (id,name,age,city,cs_level)修改，我们不会简单的直接进行update，通常会进行数据历史记录。比如最简单的user表增加一个is_valid字段，利用主键id自增的特性，把它当做用户信息更新版本号。每次更新用户信息，将原信息is_valid置为false。然后用新信息去构建一条is_valid=true数据。这样就可以完成版本记录追溯。

MVCC的数据快照、数据版本链就是是类似效果。但是在并发事务里读写，具体原理会复杂很多。

2.1 解密-基于undoLog实现的数据版本链

在MySQL表里，有2个隐藏的字段，一个是事务的ID：trx_id，这个事务id就是最近一次更新该数据的事务id；另一个是回滚指针：roll_pointer ，该指针指向的就是更新该数据之前的undoLog，可以通俗理解为：修改前数据。据此，隐藏的事务id，和回滚指针的意义，一目了然，一个表示哪个事务更新了该数据，一个表示该数据更新前的样子。

比如下图：事务trx_id=98的操作，新增了name=【拉丁解牛说技术】的这行数据。新增数据的时候，roll_pointer是空。此后，事务99对该数据进行修改，把name改为=【老牛】。此时如下图，回滚指针指向老版本事务98的数据。这样数据版本链清晰可见。

另外说一下，在MVCC里只有更新、删除、新增操作有让事务ID新增，查询是不会让数据事务发生变化。

2.2 弯弯绕绕看不懂的readView视图-一句话总结看懂

readview顾名思义是读视图，当开启一个事务，MySQL会根据当前事务隔离级别，给你这个事务开启独立的review视图空间。这里很多博文在讲解readview机制时候，会对当前最大max_trx_id最小,min_trx_id，当前事务this_trx_id，视图开启时候活跃的事务id组等多个事务id进行比较说明，讲的非常细。不过这里的判断规则说这么细，如果读者些微没跟上，或者失去耐心，可能就错失理解掌握readview的核心机制。

我们坚持大道至简的方法，总结readview视图核心机制，最直接一句话：每个事务只能读到对应事务隔离级别的数据。

我们简单举例说一下：

如下图，当前事务隔离级别是可重复读RP，并发事务100要重复多次查询，事务101 要更新name为【zhangsan】。事务并发开始前如下：

接下来具体操作：

1、事务id=100进行查询，首先查到了事务99的数据，发现自己的事务ID100比99大，直接返回读到该数据【老牛】。

2、接下来事务id=101，把数据更新为【zhangsan】并提交更新trx_id=101，回滚指针指向了之前trx_id=99的老数据。

3、事务100，继续重复读，这时候读到了trx_id=101的最新数据，发现比自己的trx_id=100还大。在当前每个事务只能读到对应事务隔离级别的数据原则下,而且当前事务隔离级别是可重复读RP。按规则，不好意思，这个101事务修改的数据我不能读，得继续遍历undoLog版本链，找到了下一个事务id=99的数据【老牛】，发现99< 100，非常好，符合事务隔离级别要求。那这次重复读，读的还是之前的数据【老牛】。

同样道理，如果是事务隔离级别在读已提交、读未提交，判断规则也只是对应判断当前自己的事务ID与读到的数据事务id大小关系是否满足事务隔离级别即可。

当然，这里核心再详细展开确实有很多细节，比如读已提交隔离级别下，每次查询，就是开启一个新的readview。这个和可重复读隔离级别不一样。

理解了MVCC核心原理，我们设计场景，在InnoDB默认的事务隔离级别「可重复读RP」下，一步步实践验证解决脏读、幻读、不可重复读问题。

三、MVCC解决脏读、不可重复读、幻读问题demo详解

新建一个user_mvcc_demo表，多个事务并发读、修改name值、以及新增写入，来具体验证mvcc核心机制。

CREATE TABLE user_mvcc_demo (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(16) DEFAULT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
-- 新增一条数据，id=1
insert into user_mvcc_demo(name)values ('拉丁解牛说技术001');