代码编织梦想

前言

很多人在谈起mysql事务的时候都能很快的答出mysql的几种事务隔离级别,以及在各自隔离级别下产生的问题,但是一旦谈到为什么会产生这样的结果时会觉得难以回答,说到底,还是对底层的原理未做深入的探究,本篇将从较为底层的原理层面来聊聊关于mysql的mvcc原理,了解并掌握了mvcc原理,也就能真正回答这些问题了。

一、mysql 数据写入磁盘流程

在了解mvcc原理之前,先来看下面这种图,这是一张关于客户端发起一条update 数据的语句时,mysql 的innodb引擎所作的一些列操作过程(可按照前面的序列号);

 

从这张图,我们提取如下关键信息:

  • update 语句到达mysql的innodb引擎之后,并不是直接操作磁盘进行数据修改,而是先将磁盘数据load到buffer pool(如果没有的话);
  • buffer poo中update完成之后,并不是立即刷到磁盘,还需要将数据写到 undolog和redolog;
  • undolog记录了数据修改前的记录,redolog记录的是事务提交时数据页的物理修改;
  • 提交事务时,数据刷写到磁盘,同时把所有修改信息都存到该日志文件(redolog), 于在刷新脏页到磁盘,发生错误时, 进行数据恢复使用;
  • 数据确认落盘成功后,redolog就没有作用了,innodb将会自动清理redolog;

从上面的分析中,可以看出,redolog文件在整个执行过程中起到了非常重要的作用,有必要对该文件做一些深入的了解和学习;

二、redo log

又叫重做日志,记录的是事务提交时数据页的物理修改,用来实现事务的持久性

redo log 日志文件由两部分组成:

  • 重做日志缓冲(redo log buffer),保存在内存中,容易丢失,对应于mysql配置文件参数为:innodb_log_buffer_size,redo log buffer 大小,默认 16M ,最大值是4096M,最小值为1M,可以通过命令:show variables like '%innodb_log_buffer_size%' 进行查看;
  • 以及重做日志文件(redo logfile),保存在磁盘中,是持久的;

1、redolog 的整体流程

仍然以上面流程图中的更新一条数据的事务过程分析,来看redolog的整体流转过程

 

具体步骤如下:
  • 将原始数据从磁盘中load到内存,修改数据的内存拷贝(buffer pool);
  • 生成一条重做日志,并写入redo log buffer,记录的是数据被修改后的值;
  • 事务commit时,将redo log buffer中的内容刷新到 redo log file,对 redo log file采用追加
    写的方式;
  • 定期将内存中修改的数据刷新到磁盘中;

2、为什么需要 redo log

InnoDB引擎中的内存结构中,主要内存区域就是缓冲池, 在缓冲池中缓存了很多的数 据页(磁盘中读取mysql数据时一般以数据页为单位进行加载);
在一个事务执行中,比如执行多个增删改的操作时, InnoDB 引擎会先操作缓冲池中的数据,如果
缓冲区没有对应的数据,再通过后台线程将磁盘中数据load出来,放到缓冲区,然后修改缓冲池中 的数据,修改后的数据页我们称为脏页;
而脏页则会在一定的时机,通过后台线程刷新到磁盘中,从而保证缓冲区与磁盘的数据一致。
但是缓冲区脏页数据并不是实时刷新的,而是隔一段时间后才将缓冲区的数据刷到磁盘中。
假如刷新到磁盘的过程出错了,而提示给用户事务提交成功,而数据却 没有持久化下来,这就出现问题了,没有保证事务的持久性。
有了 redolog 之后,当对缓冲区的数据进行增删改之后,会首先将操作的数据页的变化,记录在 redo log buffer中。在事务提交时,会将 redo log buffer 中的数据刷新到 redo log 磁盘文件中。
过一段时间后,如果刷新缓冲区的脏页到磁盘时,发生错误,此时就可以借助于 redo log 进行数据 恢复,这样就保证了事务的持久性。 而如果脏页成功刷新到磁盘 或 或者涉及到的数据已经落盘,此 时redolog 就没有作用了,就可以删除了,所以存在的两个 redolog 文件是循环写的。
说到这里就有伙伴要问,为什么每一次提交事务,要刷新 redo log 到磁盘中呢,而不是直接将 buffer pool 中的脏页刷新 到磁盘呢?
因为客户端与mysql进行数据交互(IO)过程中,们操作数据一般都是随机读写磁盘的(随机读写比较慢),而不是顺序读写磁盘(顺序读写块)。 而 redo log 在 往磁盘文件中写入数据,由于是日志文件,所以都是顺序写的。顺序写的效率,要远大于随机写。 这 种先写日志的方式,也称之为 WAL Write-Ahead Logging )。

三、undo log

undo log 也成为回滚日志,用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚 ( 保证事务的原子性 ) 和 MVCC(多版本并发控制 )

举例来说,本次使用update语句修改了一条id为1的数据,如果事务提交失败,那么就需要回滚数据,mysql引擎怎么知道回滚到哪里呢?那就要借助undo log了,undolog中记录了修改之前的数据,所以就可以用于事务回滚。

1、undo log 特点

  • undo logredo log记录物理日志不一样,它是逻辑日志;
  • 当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的 update记录;
  • 执行rollback时,就可以从undo log中的逻辑记录读取到相应的内容并进行回滚;

2、undo log 类型

InnoDB 存储引擎中, undo log 分为:
  • insert undo log;
  • update undo log;

3、undo log 生成过程

从文章开头的流程图中再简单抽象出下面的简化执行步骤

 

在开启一个事务对一条数据记录进行update的时候,对于这条数据行来说,其底层存储的结构大概长下面这样;

 在这行记录中,对应着两个隐藏字段,事务ID和回滚指针,当执行一条insert语句时,

begin ;
insert into user (name) values ( "tom" );

对于 undolog 来说,记录的数据状态将会呈现如下效果,可以看到,在这条记录中,回滚指针指向了一条数据激励,记录了这条数据的源信息,通过一个undo no标识;

 

执行update的时候,数据行记录变更,同时在redo log 回滚指针链上将增加一条记录,并连接上一条记录;

 继续执行一个update语句:

UPDATE user SET name ='jike'   WHERE id= 1 ;

 

4、undo log 回滚过程

如果事务回滚,执行rollback,对应的流程如下:

  • 通过undo no=3的日志把name='jike'的数据删除;
  • 通过undo no=2的日志把id=1的数据的deletemark还原成0;
  • 通过undo no=1的日志把id=1的数据的name还原成Tom;
  • 通过undo no=0的日志把id=1的数据删除;

5、undo log的删除

undo log的删除分成2种

  • 针对于insert undo log,因为insert操作的记录,只对事务本身可见,对其他事务不可见。故该undo log可以在事务提交后直接删除,不需要进行purge操作;
  • 针对于update undo log,该undo log可能需要提供MVCC机制,因此不能在事务提交时就进行删除。提交时放入undo log链表,等待purge线程进行最后的删除;

四、mvcc

1、什么是MVCC

全称:多版本并发控制,MVCC 是通过数据行的多个版本管理来实现数据库的并发控制。通过这项技术,使得在InnoDB的事务隔离级别下执行 一致性读操作有了保证。换言之,就是为了查询一些正在被另一个事务更新的数据行,并且可以看到它们被更新之前的值,这样在做查询的时候就不用等待另一个事务释放锁。

2、MVCC组成

mvcc的实现主要依赖下面的3个主要逻辑实现,分别是:

  • 隐藏字段,在上文中有所交待,每个数据行都会存在一个隐藏字段;
  • undolog版本链,上文有所交待,记录了回滚数据行的数据;
  • ReadView(读视图)是快照读SQL执行时MVCC提取数据的依据,记录并维护系统当前活跃的事务(未提交的)id,可能是一个数组;

 

3、快照读与当前读

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能,用更好的方式去处理读-写冲突,这样即使有读写冲突时,也能做到不加锁,非阻塞并发读 ,而这个读指的就是快照读,而非当前读。当前读实际上是一种加锁的操作,是悲观锁的实现,而MVCC本质是采用乐观锁思想的一种方式。

快照读


快照读又叫一致性读,读取的是快照数据。不加锁的简单的 SELECT 都属于快照读,即不加锁的非阻塞读;比如这样:
 

SELECT * FROM player WHERE ...

之所以出现快照读的情况,是基于提高并发性能的考虑,快照读的实现是基于MVCC,它在很多情况下,避免了加锁操作,降低了开销。

既然是基于多版本,那么快照读可能读到的并不一定是数据的最新版本,而有可能是之前的历史版本。快照读的前提是隔离级别不是串行级别,串行级别下的快照读会退化成当前读。

当前读

当前读读取的是记录的最新版本(最新数据,而不是历史版本的数据),读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。加锁的 SELECT,或者对数据进行增删改都会进行当前读。比如:

SELECT * FROM student LOCK IN SHARE MODE; # 共享锁

SELECT * FROM student FOR UPDATE; # 排他锁

INSERT INTO student values ... # 排他锁

DELETE FROM student WHERE ... # 排他锁

五、mvcc操作演示

来看下面这一些列的事务操作过程,如下是一组操作同一条数据的记录的多个事务,从事务2 ~ 事务5,分别对应不同的操作何阶段;

 

从上文我们对undolog的了解,每次修改一条数据时,会在undolog 回滚链中增加一条记录,用于后续做数据回滚;

具体步骤如下:

比如当事务2执行第一条修改语句时,会记录一条undo log日志,记录了当前数据变更之前的样子; 然后更新记录,并且记录本次操作的事务ID,回滚指针,回滚指针用来指定如果发生回滚,回滚到哪一个版本;

 

当事务 3 执行第一条修改语句时,也会记录 undo log 日志,记录数据变更之前的样子 ; 然后更新记
录,并且记录本次操作的事务 ID ,回滚指针,回滚指针用来指定如果发生回滚,回滚到哪一个版本;

 

当事务 4 执行第一条修改语句时,也会记录 undo log 日志,记录数据变更之前的样子 ; 然后更新记
录,并且记录本次操作的事务 ID ,回滚指针,回滚指针用来指定如果发生回滚,回滚到哪一个版本;

通过上面一些列的操作,最终会发现,不同事务或相同事务对同一条记录进行修改,会导致该记录的 undolog 生成一条 记录版本链表,链表的头部是最新的旧记录,链表尾部是最早的旧记录。

 有了上面的redo log 的回链,最终是怎么确定某个事务读取的数据是长什么样子呢?接下来 readview就派上用场了;

ReadView (读视图)是 快照读 SQL 执行时 MVCC 提取数据的依据,记录并维护系统当前活跃的事务 (未提交的)id;

ReadView中包含了四个核心字段:
字段
含义
m_ids
当前活跃事务 ID 集合
min_trx_id
最小活跃事务 ID
max_trx_id
预分配事务 ID ,当前最大事务 ID+1 (因为事务 ID 是自增的)
creator_trx_id
ReadView 创建者事务 ID
而在 readview 中就规定了版本链数据的访问规则,

trx_id 代表当前undolog版本链对应事务ID

完整的匹配规则如下:
条件
是否可以访问
说明
trx_id ==
creator_trx_id
可以访问该版本
成立,说明数据是当前这个事
务更改的
trx_id < min_trx_id
可以访问该版本
成立,说明数据已经提交了
trx_id > max_trx_id
不可以访问该版本
成立,说明该事务是在
ReadView 生成后才开启
min_trx_id <= trx_id
<= max_trx_id
如果 trx_id 不在 m_ids 中,
是可以访问该版本的
成立,说明数据已经提交

不同的隔离级别,生成ReadView的时机不同:
  • READ COMMITTED (读已提交):在事务中每一次执行快照读时生成ReadView;
  • REPEATABLE READ(可重复读):仅在事务中第一次执行快照读时生成ReadView,后续复用该ReadView;

也就是说,在利用mvcc的多版本并发控制时,只需要关注这两种事务隔离级别就行了,接下来,以上午的excel中展示的几个事务为例,对照这两种类型的事务隔离级别进行说明;

1、READ COMMITTED 隔离级别

以事务5为例进行说明,两次快照读读取数据时,是如何获取数据的?

在事务 5 中,查询了两次 id 30 的记录,由于隔离级别为 Read Committed ,所以每一次进行快照读
都会生成一个 ReadView ,那么两次生成的 ReadView 如下

 

那么这两次快照读在获取数据时,就需根据所生成的 ReadView 以及 ReadView 的版本链访问规则, 到undolog 版本链中匹配数据,最终决定此次快照读返回的数据;
先来看第一次快照读具体的读取过程
对应的undo log 版本链如下

 

在进行匹配时,会从undo log的版本链,从上到下进行挨个匹配:

1)先匹配下面这条记录,这条记录对应的trx_id为4,也就是将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 , 都不满足,则继续匹配undo log版本链的下一条;

 

2) 再匹配第二条记录, 这条 记录对应的 trx_id 3 ,也就是将 3 带入右侧的匹配规则中。①不满足 ②不满足 ③不满足 ④也 不满足 ,都不满足,则继续匹配 undo log 版本链的下一条;

 

3)再匹配第三条记录,这条记 录对应的trx_id2,也就是将2带入右侧的匹配规则中。①不满足 ②满足 终止匹配,此次快照 读,返回的数据就是版本链中记录的这条数据;

 

再来看第二次快照读具体的读取过程:

 对应的undolog 版本链如下:

 

在进行匹配时,会从 undo log 的版本链,从上到下进行挨个匹配:

1)先匹配这条记录,这条记录对应的 trx_id为4,也就是将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 , 都不满足,则继续匹配undo log版本链的下一条;

 

2)再匹配第二条, 这条 记录对应的 trx_id 3 ,也就是将 3 带入右侧的匹配规则中。①不满足 ②满足 。终止匹配,此次 快照读,返回的数据就是版本链中记录的这条数据;

 

2、REPEATABLE READ 隔离级别

在这种隔离级别下,仅在事务中第一次执行快照读时生成 ReadView ,后续继续复用该 ReadView 。 而 可重复读在一个事务中,执行两次相同的select 语句,查询到的结果是一样的;
MySQL 是如何做到可重复读的呢 ? 按照上面的过程做一下类似的分析

 

可以看到,在可重复读这种事务 隔离级别下,只在事务中第一次快照读时生成 ReadView ,后续都复用该 ReadView。既然 ReadView 都一样, ReadView 版本链匹配规则也一样, 最终快照读返 回的结果也是一样的了。

总结

  • MVCC实现原理是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的;
  • MVCC + 锁,则实现了事务的隔离性;
  • 一致性则是由redolog undolog保证;

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/zhangcongyi420/article/details/127471095

MySQL MVCC机制详解-爱代码爱编程

MySQL MVCC机制详解 MVCC分析参考文献 MVCC分析   MySQL默认的事务隔离级别是可重复读,在事务开始时获得一致性视图,但更新数据时需要拿到行锁,如果与其他事务出现冲突需要进行等待,等待后获得锁再进行更新操作时读到的值是最新值还是创建一致性视图时的值呢?下面我们通过一个实验来验证。   下面为一张表的创建语句: mysql

activity任意节点动态加签-爱代码爱编程

前言 在之前的章节中,我们聊到了activity可以解决动态的任意加签节点的问题,但那时候我们的加签节点是临时存储的,而在现实的业务中,往往需要通过创建自身的业务表与activity的表建立一定的业务关系,从而实现数据持久化,即我们加签的节点不能因为加签完毕后就找不到历史数据了 activity和mybatis实现了较好了的整合,如果采用spring的

Mysql中MVCC的使用及原理详解-爱代码爱编程

Mysql中MVCC的使用及原理详解 准备 测试环境:Mysql 5.7.20-log 数据库默认隔离级别:RR(Repeatable Read,可重复读),MVCC主要适用于Mysql的RC,RR隔离级别 创建一张存储引擎为testmvcc的表,sql为: CREATE TABLE testmvcc ( id int(11) DEFAULT

mysql数据库事务,MVCC原理详解-爱代码爱编程

大家好,我是java小杰要加油, 今天来分享一个京东面试真题,也是这是我前阵子听我旁边高T(高,实在是高)面试候选人的时候问的一个问题,他问,你能说说 mysql的事务吗? MVCC有了解吗? 话不多说,直接开干事务定义及四大特性 事务是什么? 就是用户定义的一系列数据库操作,这些操作可以视为一个完成的逻辑处理工作单元,要么全部执行,要么全

mysql mvcc_MYSQL MVCC实现原理详解-爱代码爱编程

MVCC(Multi Version Concurrency Control的简称),代表多版本并发控制。与MVCC相对的,是基于锁的并发控制,Lock-Based Concurrency Control)。 MVCC最大的优势:读不加锁,读写不冲突。在读多写少的OLTP应用中,读写不冲突是非常重要的,极大的增加了系统的并发性能 了解MVCC前,我

mysql的mvcc实现原理详解_Mysql MVCC实现原理解析(仅学习)-爱代码爱编程

MVCC(Multi-Version Concurrency Control | 多版本并发控制) InnoDB通过为每一行记录添加两个额外的隐藏的值来实现MVCC,这两个值一个记录这行数据何时被创建,另外一个记录这行数据何时过期(或者被删除)。但是InnoDB并不存储这些事件发生时的实际时间,相反它只存储这些事件发生时的系统版本号(LSN)。这是一

mysql的mvcc实现原理详解_MYSQL MVCC实现原理分析-爱代码爱编程

MYSQL MVCC实现原理分析2020-12-07 06:40:10 MVCC(Multi Version Concurrency Control的简称),代表多版本并发控制。与MVCC相对的,是基于锁的并发控制,Lock-Based Concurrency Control)。 MVCC最大的优势:读不加锁,读写不冲突。在读多写少的OLTP应用

MySQL 事务与 MVCC 原理 详解-爱代码爱编程

什么是事务? 数据库事务指的是一组数据操作,事务内的操作要么就是全部成功,要么就是全部失败,什么都不做,其实不是没做,是可能做了一部分但是只要有一步失败,就要回滚所有操作,有点一不做二不休的意思。 在 MySQL 中,事务支持是在引擎层实现的。MySQL 是一个支持多引擎的系统,但并不是所有的引擎都支持事务。比如 MySQL 原生的 MyISAM 引擎

硬核解析mysql的mvcc实现原理,面试官看了都直呼内行_肥肥技术宅的博客-爱代码爱编程

1. 什么是MVCC MVCC全称是Multi-Version Concurrency Control(多版本并发控制),是一种并发控制的方法,通过维护一个数据的多个版本,减少读写操作的冲突。 如果没有MVCC,想要实现同一条数据的并发读写,还要保证数据的安全性,就需要操作数据的时候加读锁和写锁,这样就降低了数据库的并发性能。 有了MVCC,就相当于

mysql 的 mvcc 原理详解_mvcc会加锁吗-爱代码爱编程

什么是 MVCC ? mvcc,全称 multi-version concurrency control,即多版本并发控制mvcc 是 mysql 的 innodb 引擎为了解决读写冲突,通过不加锁的方式而实现的一种解决冲