【MySQL进阶-05】深入理解mvcc机制(详解)(1)，2024年最新普通二本的辛酸Golang面试之路

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

内容	链接地址
【一】深入理解mysql索引本质	https://blog.csdn.net/zhenghuishengq/article/details/121027025
【二】深入理解mysql索引优化以及explain关键字	https://blog.csdn.net/zhenghuishengq/article/details/124552080
【三】深入理解mysql的索引分类，覆盖索引(失效)，回表，MRR	https://blog.csdn.net/zhenghuishengq/article/details/128273593
【四】深入理解mysql事务本质	https://blog.csdn.net/zhenghuishengq/article/details/127753772
【五】深入理解mvcc机制	https://blog.csdn.net/zhenghuishengq/article/details/127889365
【六】深入理解mysql的内核查询成本计算	https://blog.csdn.net/zhenghuishengq/article/details/128820477
【七】深入理解mysql性能优化以及解决慢查询问题	https://blog.csdn.net/zhenghuishengq/article/details/128854433
【八】深入理解innodb和buffer pool底层结构和原理	https://blog.csdn.net/zhenghuishengq/article/details/128993871
【九】深入理解mysql执行的底层机制	https://blog.csdn.net/zhenghuishengq/article/details/128100377
【十】深入理解mysql集群的高可用机制	https://blog.csdn.net/zhenghuishengq/article/details/126239652
【彩蛋篇】深入理解顺序io和随机io	https://blog.csdn.net/zhenghuishengq/article/details/129080088

---

深入理解mvcc机制

• 一，MVCC定义
• • 1，undolog日志

• 2，undolog版本控制链
• 3，readView
• • 3.1，readview简介

• 3.2，readview和undolog结合使用规则
• 3.3，readview和undolog基本使用

• 4，总结

一，MVCC定义

MVCC：Multi-Version Concurrency Control，多版本并发控制机制。

在mysql中，为了满足事务的四大特性之一的隔离性，就是当前事务中的查询的数据不受其他事务的增删改操作的影响，因此mysql主要是通过这个可串行化的这种隔离级别和现在即将要谈的mvcc机制来实现。而可串行化就是将所有的操作由并行改为串行，就是在每个增删改包括查操作上面都加了锁，因此性能非常的低，因此mysql也并没有选择这个可串行化来作为mysql的默认的隔离级别，而是使用的可重复读。接下来就是主要谈一下这个可重复读事务中的mvcc的机制和底层原理。

1，undolog日志

在讲mvcc机制之前，需要先了解一下这个undolog日志。在mysql中，如果使用的是默认的可重复读的这个隔离级别，在一条更新语句中如果加了事务，那么在这个事务启动之后，提交之前，那么这条数据是暂时不会添加到数据库的，直到事务提交成功才会提交或者更新到数据库。那么中间就需要实现数据的暂存，那么这种存储的方式就是通过这个undolog日志的的是实现的。

CREATE TABLE product (
id bigint(20) NOT NULL,
product_id int(11) DEFAULT NULL COMMENT ‘商品id’,
version int(11) DEFAULT NULL COMMENT ‘版本’,
stock int(11) DEFAULT NULL COMMENT ‘商品数量’,
updated_time datetime DEFAULT NULL COMMENT ‘更新时间’,
created_time datetime DEFAULT NULL COMMENT ‘创建时间’,
is_deleted tinyint(4) DEFAULT NULL COMMENT ‘是否删除’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

如上，创建一张表，然后里面新增一条数据

insert into stock values (1,1,0,100,now(),now(),0);

拿一条更新语句来说，如上面一张商品表，接下来要扣减一件商品的库存，一开始这件商品有100，那么现在扣减20，如果扣减成功，那么数据库的值就是80

update product set stock = stock - 20 where id = 1;

如果在扣减数据时，发生异常出现回滚，那么此时就需要回滚成之前的值，就是需要一个日志来记录扣减之前的值，那么就是通过这个undolog来记录的。就是说在这个update更新语句中，在开启事务之后，提交事务之前，这个库存100就会记录在undolog日志里面，减完后的80这个值如果整个事务没有出现异常那么就直接加入到数据库里面，如果出现异常那么就将undolog里面的值作为回滚数据。一句话说这个undolog日志就是用来记录被修改的值，防止出现异常回滚的

2，undolog版本控制链

当然这个undolog日志也不是只记录一条，如在一个或者多个事务中对这个库存进行了多次的修改，那么这个undolog就会形成一条历史版本控制链。在这个版本控制链中，有一个隐藏的事务id和指针。事务id在新增或者更新都会生成一个事务id，默认自增(重点)；指针所指向的就是当前数据修改前的一个历史数据，如果出现了回滚，那么就会根据这个链路依次的往前回滚，直到找到上一个或者前面几个。

这个事务id是在sql更新或者新增的时候生成，并非事务提交的时候生成，因此可能出现事务大的id先提交，那么版本控制链路里面的事务id的大小就是乱序的。

3，readView

3.1，readview简介

在上面的undolog日志里面，可以发现确实时记录了所有的修改的值，也知道这个undolog是用来回滚的，但是会存在一个问题，如果单纯使用一个undolog来解决这个回滚问题，那么就会不知道回滚到链路中的哪一个结点，因此就需要引入这个readView来和这个undolog结合使用，通过readview来知道需要回滚到链路的哪一个结点。

在一个事务里面，执行任何查询都会生成当前事务的一致性视图read-view，在可重复读中的事务隔离级别中，该视图在事务结束之前都不会变化。当然如果是读已提交的隔离级别那么在每次执行sql时都会重新生成视图。

在可重复读的事务里面，这个readview视图由未提交的事务id数组和已创建的最大事务id(max_id)组成，因此这个最大的 max_id 可能在数组里面，也可能不在，因为事务最大的id可能先提交，而数组里面的id都是未提交的。

[trx_id1,trx_id2],max_id

如上图，有四个事务ABCD，同时开启事务，同时去操作这个商品表的库存，事务ABC在执行更新语句之后，就会产生一个事务id，因为事务id是自增的，因此从左往右事务依次递增。而事务D里面主要是用来查询，并无增删改操作，主要是查询当前事务中的库存的数量，由于没有更新和查询语句，因此也没有事务id。由于三个事务是同时开始，因此commit提交的时间取决于更新语句的时间，谁先更新完谁先提交，因此可能会出现事务大的id先提交。

上图主要是针对库存表中id为1的那一行数据进行操作的，而id=2只是为了通过更新语句给这个事务生成一个事务id。

并且mvcc机制主要是针对于可重复读的这个隔离级别，因此在D中暂时只考虑查询有其他事务提交的数据，未提交之前的数据暂时不做select查询考虑

3.2，readview和undolog结合使用规则

在使用这个readview只能看到当前的几个事务，并且不能得知事务的提交顺序，因此需要结合上面所说的undolog一起使用。在两者结合使用之前，需要有一个readview视图和undolog版本的比对规则，接下来先详细的说一下这个比对规则的一些命名：假设这个数组中未提交的的事务id数组的最小值假设为min_id，已创建事务的事务id的最大id为max_id，undolog版本控制链的头结点为head结点。如在下面的第三个select查询语句中，min_id = 102 ， max_id = 104。

然后以这个min_id和这个max_id为分界处，小于这个min_id的为已提交事务，在这两个值区间的为未提交或者已提交事务，大于这个max_id的，为未开始事务。

那么规则如下：

head结点的事务id <= min_Id：已提交的事务，该事务是可见的

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）**
[外链图片转存中…(img-A6zxKzd6-1713176584178)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！