MVCC 底层原理详解

已于 2023-08-24 21:45:49 修改
阅读量995 收藏 4
点赞数 8
分类专栏： MySQL 文章标签： mysql 数据库 java
于 2022-06-16 21:25:45 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_56263094/article/details/125317049
版权

大家好 我是积极向上的湘锅锅💪💪💪

基本概念

当前读

顾名思义，读取的就是当前最新的版本，而且读取的时候保证其他并发事务不会修改该记录，会对记录加锁（共享锁或者是排它锁），如：select … lock in share mode(共享锁)，select …
for update、update、insert、delete(排他锁)都是一种当前读

快照读

简单的 select（不加锁）就是快照读，快照读读取的可能是最新版本，也有可能是历史数据

Read Committed：每个select都会产生一个快照读

Repeatable Read：开启事务后第一个select才是快照读的地方

Serializable：快照读会退化为当前读（加锁）

MVCC

全称Multi-Version Concurrency Control，多版本并发控制，指维护一个数据的多个版本，使得读写操作没有冲突，也就是不会产生读写锁冲突，而快照读为MySQL实现MVCC提供了一个非阻塞读功能，这给我们高并发性能提升不少

MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView

接下来，我们再来介绍一下InnoDB引擎的表中涉及到的隐藏字段 、undolog 以及 readview，从
而来介绍一下MVCC的原理。

隐藏字段

在这里插入图片描述
举个例子当我们创建了这张表，在查看表结构的时候，只看得到这三个显示的字段，但是实际上除了这三个字段意外，InnoDB还会自动的给我们添加三个隐藏字段，如下：
在这里插入图片描述
而上面前俩个字段是肯定添加的，而第三个要看是否自己设置了主键，如果没有指定主键，则会添加该字段

undolog

回滚日志，在insert，update，delete的时候产生便于数据回滚的日志

  • 在insert的时候，产生的undo log 日志旨在回滚的时候需要，在事务提交后，可被立即删除
  • 而update，delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除

版本链

为什么叫版本链，慢慢往下看…

有一张表的原始数据为：
在这里插入图片描述

DB_TRX_ID : 代表最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID，是自增的

DB_ROLL_PTR ： 指向上一个版本，由于这条数据是才插入的，没有被更新过，所以该字段值为null。

然后，有四个并发事务同时在访问这张表

第一步

在这里插入图片描述
当事务2开始修改数据时，会产生undo log日志，记录数据变更之前的样子，并且会记录本次操作的事务id
在这里插入图片描述

第二步

在这里插入图片描述
当事务3执行第一条修改语句时，也会记录记录undo log日志，记录数据变更之前的样子，然后更新版本记录，并且记录本次操作事务id
在这里插入图片描述

第三步

在这里插入图片描述
当事务4执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记
录，并且记录本次操作的事务ID
在这里插入图片描述
最终我们发现，不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条
记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录

Readview

Readview（读视图）是快照读SQL执行的时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id
Redaview中包含了四个核心字段：
在这里插入图片描述
看图有点抽象，我觉得可以这样理解

  • m_ids：当前活跃的事务ID集合 ==>当前并发过程中还未提交的事务ID集合
  • min_trx_id：最小活跃事务ID ==>在还未提交的事务ID集合中最小那个
  • max_trx_id：预分配事务ID，当前最大事务ID+1 ==>也就是说下一个事务ID应该是当前还未提交的事务id集合中最大那个ID+1
  • creator_trx_id：ReadView创建者的事务ID ==>这个好理解 就是哪个事务创建的这个ReadView那就是那个事务的ID
  • 如果还有疑问下面还有图帮助理解哦，觉得有帮助请点个赞

而在readview中就规定了版本链数据的访问规则：
trx_id 代表当前undolog版本链对应事务ID
在这里插入图片描述
看这可能有的小伙伴有点懵 我对这张图解释一下，不对之处请指出

  • trx_id 可以理解为每一条匹配的undo log版本链的事务ID，也就是哪个事务ID产生的这条记录
  • 是从版本链尾部到头部开始匹配
  • 如果trx_id == creator_trx_id那就说明改记录是自己所在的事务更改的，是一家人，那肯定可以访问该版本
  • 如果trx_id < min_trx_id，也就是说访问的这个事务已经提交了，因为目前还未结束的事务ID都比它大，那就可以访问该版本
  • 如果trx_id > max_trx_id，那就说明已经有事务在生成ReadView之后开启了，我们肯定不能访问该版本，防止产生重复读的问题
  • 如果min_trx_id <= trx_id <=max_trx_id，如果trx_id不在m_ids集合里面，那就说明该事务已经提交了，提交了我们肯定可以访问，如果没有提交，那就不能访问

不同的隔离级别，生成ReadView的时机不同

  • READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。
  • READ REPEATABLE：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。

原理分析

1.RC隔离级别

RC隔离级别下，在事务中每一次执行快照读时生成ReadView。

我们就来分析事务5中，两次快照读读取数据，是如何获取数据的?
在事务5中，查询了两次id为30的记录，由于隔离级别为Read Committed，所以每一次进行快照读
都会生成一个ReadView，那么两次生成的ReadView如下：
在这里插入图片描述
这里有图也可以好好理解一下ReadView每一个字段所代表的具体含义
那么俩次快照读在获取数据的时候，就需要根据所生成的ReadView和ReadView的版本链访问规则，到undo log版本练中匹配数据，最终决定此次快照读使用哪一条记录的数据

A.先来看第一次快照读具体的读取过程
在这里插入图片描述
下图是版本链和访问规则
在这里插入图片描述在进行匹配时，会从undo log的版本链，从上到下进行挨个匹配：

  • 先匹配这条记录在这里插入图片描述
    这条记录对应的trx_id为4，也就是将4带入右侧的匹配规则中
    ①不满足 ②不满足 ③不满足 ④也不满足 ，
    都不满足，则继续匹配undo log版本链的下一条

  • 再匹配第二条在这里插入图片描述
    这条记录对应的trx_id为3，也就是将3带入右侧的匹配规则中。
    ①不满足 ②不满足 ③不满足 ④也不满足
    都不满足，则继续匹配undo log版本链的下一条

  • 再匹配第三条在这里插入图片描述
    这条记录对应的trx_id为2，也就是将2带入右侧的匹配规则中。
    ①不满足 ②满足
    终止匹配
    此次快照读，返回的数据就是版本链中trx_id为2记录的这条数据

B. 再来看第二次快照读具体的读取过程
在这里插入图片描述
上图中注意第二次快照读是下面那个ReadView
在这里插入图片描述

  • 先匹配这条记录
    在这里插入图片描述
    这条记录对应的trx_id为4，也就是将4带入右侧的匹配规则中
    ①不满足 ②不满足 ③不满足 ④也不满足
    都不满足，则继续匹配undo log版本链的下一条

  • 再匹配第二条
    在这里插入图片描述
    这条记录对应的trx_id为3，也就是将3带入右侧的匹配规则中。
    ①不满足 ②满足
    终止匹配
    此次快照读，返回的数据就是版本链中记录的这条数据

2. RR隔离级别

RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。 而RR 是可
重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的
那在MVCC的机制下，是如何防止可重复读的呢？
还是用事务5举例
在这里插入图片描述
我们看到，在RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该
ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返
回的结果也是一样的

结论

所以呢，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的，而MVCC + 锁（next-key ），则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证

InnoDB MVCC实现原理及源码解析
帅的数说
04-15 3035
1、原理介绍数据多版本(MVCC)是MySQL实现高性能的一个主要的一个主要方式，通过对普通的SELECT不加锁，直接利用MVCC读取指版本的值，避免了对数据重复加锁的过程。InnoDB支持MVCC多版本，其中RC和RR隔离级别是利用consistent read view方式支持的，即在某个时刻对事物系统打快照记下所有活跃读写事务ID，之后读操作根据事务ID与快照中的事务ID进行比较，判断可见性...
mysql mvcc 原理详解
congge
10-23 4412
mysql mvcc原理解读
MVCC 底层实现原理
刘元雄
11-16 1562
MVCC 底层实现原理
MVCC底层原理实现
Shine19的博客
04-15 1145
指的是一种提高并发的技术。最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了InnoDB的并发度。在内部实现中，InnoDB通过undo log保存每条数据的多个版本，并且能够找回数据历史版本提供给用户读，每个事务读到的数据版本可能是不一样的。在同一个事务中，用户只能看到该事务创建快照之前已经提交的修改和该事务本身做的修改。MVCC只在已提交读（Read Committed）和可重复读。
MVCC的底层原理
qq_411664740的博客
10-15 307
事务的四大特性ACID 原子性（Atomicity）：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚， 一致性（Consistency）：一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态， 隔离性（Isolation）：一个事务不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 持久性（Durability）：持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的。 MySQL事务隔离级别 事务隔离级别 脏读 不可重复读 幻..
SQL Server中带事务的存储过程简单举例
ailinmin6788的博客
08-13 174
先来看一个概念： 　　数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作，要么完整地执行，要么完全地不执行。那么在存储过程里添加事务，则可以保证该事务里的所有sql代码要么完全执行要么完全不执行。 　　举个简单的带事务的存储过程： 　　Begin 　　　　Set NOCOUNT ON;--不返回影响行数 　　　　Set ...
MySQL MVCC底层原理详解
热门推荐
天瑕的博客
07-25 2万+
MySQL MVCC底层原理详解
Mysql锁机制与优化实践以及MVCC底层原理剖析
魔法革1996
10-26 1107
MVCC机制的实现就是通过read-view机制与undo版本链比对机制，使得不同的事务会根据数据版本链对比规则读取同一条数据在版本链上的不同版本数据。
Mysql锁机制与优化实践以及MVCC底层原理刨析
最新发布
cxl0209的博客
05-25 1016
MyISAM在执行查询语句SELECT前，会自动给涉及的所有表加读锁，在执行update、insert、delete操作会自动给涉及的表加写锁。InnoDB在执行查询语句SELECT时(非串行隔离级别)，不会加锁。但是update、insert、delete操作会加行锁。另外，读锁会阻塞写，但是不会阻塞读。而写锁则会把读和写都阻塞。
解释PostgreSQL中的MVCC（多版本并发控制）机制是如何工作的？
发现生活，分享智慧，一起成长！
04-25 1219
MVCC通过保留数据的多个版本来实现这一点，使得每个事务都可以看到它开始时的数据快照，而不会受到其他并发事务的影响。这样，每个事务都可以看到它开始时的数据状态，即使其他事务在此期间对数据进行了修改。当其他事务尝试读取该行时，它会检查该行的事务ID与当前事务的ID之间的关系，以确定该行是否对当前事务可见。由于MVCC的作用，事务A将看到它开始时的数据快照，即Alice的原始年龄，而不是事务B修改后的年龄。需要注意的是，这只是一个简化的示例，实际的MVCC实现涉及更多的细节和复杂性。
Mysql存储引擎底层剖析（详解）
weixin_58216062的博客
01-16 556
一引擎1，MySQL从3.23.34a开始就包含InnoDB存储引擎。大于等于5 .5之后，默认采用InnoDB引擎2、将每个表的数据和索引都放在一起放在.ibd文件中。3、InnoDB有两个表，一个是.ibd文件（存储数据和索引），一个是.frm(存储表结构，MySQL8.0时，合并在表名ibd中4、采用支持高并发，实现了四个标准的隔离级别，在REPEATED READ中通过实现间隙锁来防止幻读的出现。
MVCC底层实现原理
聪明不喝牛奶的博客
03-29 1305
首先 MVCC（Multi-Viewsion Concurrency Control） 又叫多版本协议控制，主要是提高数据库的并发性能。这里注意一下MVCC的落地实现是快照读。MVCC是用来解决读-写冲突的无锁并发控制，就是为事务分配单向增长的时间戳。 实现原理 判断规则 当执行查询sql时会生成一致性视图read-view，它由执行查询时所有未提交事务id数组（数组里面最小的id为min_id）和已创建的最大事务id（max_id）组成，查询的数据结果需要read-view做对比从而获得快照结果。 版本链
mvcc底层实现原理知道吗
huahua66688的博客
08-08 1884
MVCC是一种并发控制机制，通过保存数据的多个版本来支持并发读写操作。使用 MVCC 来支持事务的并发执行，并通过事务 ID 和版本号来判断数据的可见性。隔离级别影响 MVCC 的行为，不同的隔离级别有不同的可见性和锁定策略。垃圾回收是 MVCC 的一个重要部分，用于清理不再需要的数据版本。
MySQL的mvcc原理和底层
le12345678934694的博客
12-05 877
MVCCMVCC，全称，即多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。mvcc - @百度百科MVCC在中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读在学习 MVCC 多版本并发控制之前，我们必须先了解一下，什么是 MySQL InnoDB 下的当前读和快照读?当前读像 select lock in share mode (共享锁update;
MVCC底层原理讲解
yzx3105的博客
05-20 182
demo1 readview生成规则： 【查询时所有未提交的事务id数组】，已创建最大事务id 1.第一次查询的时候，readview：【100，200】 300 执行结果：lilei300 2.第二次查询的时候，由于MySQL默认可重复读，所以readview：【100，200】 300 执行结果：lilei300 3.第三次查询的时候，由于MySQL默认可重复读，所以readview：【100，200】 300 执行结果：lilei300 demo2 readview：【200】 300 执行结.
MVCC原理讲解（深入浅出）
qq_54421200的博客
01-28 4109
从以上的描述中我们可以看出来，所谓的MVCC指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程，这样子可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能。
MVCC底层原理
qq_56573709的博客
10-10 526
什么时候会获取到事务id？ RR隔离级别MVCC的可见性算法是什么？ 通过reda-view的版本链进行比对的版本链比对规则是什么？
mvcc实现原理
04-23
<think>好的，用户想了解MVCC的实现原理，需要详细解释。我需要结合之前提供的引用资料来组织回答。首先，确定MVCC的基本概念，然后分点说明实现机制，比如隐式字段、undo log、Read View等。还要注意引用标注的正确性，确保每个部分都有对应的引用来源。同时，要检查是否有用户不可见的系统级指令需要遵守，比如LaTeX格式和结构要求。可能还需要生成相关问题，但放在最后。用户可能对事务隔离级别和MVCC的关系不太清楚，所以需要明确说明。另外，需要对比当前读和快照读，这也是用户可能感兴趣的点。确保回答结构清晰，分步骤讲解，避免技术术语堆砌，让用户容易理解。</think>### MVCC实现原理详解 MVCC（多版本并发控制）是数据库管理系统中实现非阻塞读操作的核心技术，通过数据多版本管理实现读写操作并发执行。其实现依赖三个核心组件： #### 一、基础存储结构 1. **隐式字段** 每条记录包含三个系统字段（用户不可见）： - `DB_TRX_ID`（6字节）：记录最后一次修改该数据的事务ID $$示例值：事务100修改后的数据\ DB\_TRX\_ID=100$$ - `DB_ROLL_PTR`（7字节）：指向undo log的回滚指针[^3] - `DB_ROW_ID`（6字节）：隐藏自增主键（当表无主键时生成）[^2] 2. **版本链构建** 通过回滚指针形成的版本链结构： ```plaintext 当前记录 ← undo log记录v3 ← undo log记录v2 ← undo log记录v1 ``` #### 二、核心运行机制 1. **Read View生成** 事务首次读操作时生成包含四个要素的读视图： - `creator_trx_id`：当前事务ID - `m_ids`：活跃事务ID集合 - `min_trx_id`：最小活跃事务ID - `max_trx_id`：预分配的下个事务ID[^4] 2. **可见性判断算法** 按顺序检查每条记录的版本链： ``` if trx_id == creator_trx_id → 可见（当前事务修改） elif trx_id < min_trx_id → 可见（已提交事务） elif trx_id >= max_trx_id → 不可见（未来事务） elif trx_id in m_ids → 不可见（活跃事务） else → 可见（已提交事务） ``` #### 三、版本控制实现 1. **数据更新流程** - 插入新记录时生成新版本 - 更新操作会创建新版本并更新回滚指针 - 删除操作标记为删除状态[^5] 2. **清理机制** 通过`purge`线程定期清理不再需要的旧版本数据，清理条件： $$事务ID < 当前最旧活跃事务ID\ \&\&\ 无Read View依赖$$ #### 四、与事务隔离的对应关系 | 隔离级别 | 快照生成时机 | 可见性范围 | |----------------|----------------------|---------------------| | 读未提交 | 不使用MVCC | 直接读取最新数据 | | 读已提交(RC) | 每次查询生成新快照 | 已提交事务的最新版 | | 可重复读(RR) | 首次查询生成固定快照 | 事务开始时的数据版 | | 串行化 | 使用锁机制 | 无并发访问 | #### 五、读写操作类型 1. **快照读** ```sql SELECT * FROM table; -- 使用Read View读取可见版本[^2] ``` 2. **当前读** ```sql SELECT * FOR UPDATE; -- 直接读取最新数据并加锁[^3] ``` [^1]: 事务隔离机制与MVCC的关系说明 [^2]: 快照读与当前读的对比分析 [^3]: 版本链构建过程的技术实现 [^4]: Read View生成规则详述 [^5]: 数据清理机制实现原理
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

owensweat

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值