mysql中的mvcc 原理详解

目录 简介 前言 一、mysql 数据写入磁盘流程 二、redo log 1、redolog的整体流程 2、为什么需要 redo log 三、undolog 1、undolog 特点 2、undo log类型 3、undo log 生成过程 4、undo log 回滚过程 5、und

                        目录简介前言一、mysql 数据写入磁盘流程二、redo log1、redolog 的整体流程 2、为什么需要 redo log三、undo log1、undo log 特点2、undo log 类型3、undo log 生成过程4、undo log 回滚过程5、undo log的删除四、mvcc1、什么是MVCC2、MVCC组成3、快照读与当前读快照读当前读五、mvcc操作演示1、READ COMMITTED 隔离级别2、REPEATABLE READ 隔离级别

简介

MVCC（Multi-Version Concurrency Control）多版本并发控制，是用来在数据库中控制并发的方法，实现对数据库的并发访问用的。在MySQL中，MVCC只在读取已提交（Read Committed）和可重复读（Repeatable Read）两个事务级别下有效。其是通过Undo日志中的版本链和ReadView一致性视图来实现的。MVCC就是在多个事务同时存在时，SELECT语句找寻到具体是版本链上的哪个版本，然后在找到的版本上返回其中所记录的数据的过程。

首先需要知道的是，在MySQL中，会默认为我们的表后面添加三个隐藏字段：

DB_ROW_ID：行ID，MySQL的B+树索引特性要求每个表必须要有一个主键。如果没有设置的话，会自动寻找第一个不包含NULL的唯一索引列作为主键。如果还是找不到，就会在这个DB_ROW_ID上自动生成一个唯一值，以此来当作主键（该列和MVCC的关系不大）；DB_TRX_ID：事务ID，记录的是当前事务在做INSERT或UPDATE语句操作时的事务ID（DELETE语句被当做是UPDATE语句的特殊情况，后面会进行说明）；DB_ROLL_PTR：回滚指针，通过它可以将不同的版本串联起来，形成版本链。相当于链表的next指针。

注意，添加的隐藏字段并不是很多人认为的创建时间和删除时间，同时在MySQL中MVCC的实现也不是通过什么快照来实现的。之所以有这种说法可能是源自于《高性能MySQL》一书中对MySQL中MVCC的错误结论，然后就人云亦云传开了（注意，我这里一直强调的是MySQL中MVCC的实现，是因为在不同的数据库中可能会有不同的实现）。所以说看源码和看官方文档才是最权威的解释）

前言

很多人在谈起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 log和redo log记录物理日志不一样，它是逻辑日志；当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的 update记录；执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚；

2、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本质是采用乐观锁思想的一种方式。