Mysql到底是怎么实现MVCC的

Mysql到底是怎么实现MVCC的

Mysql到底是怎么实现MVCC的？这个问题无数人都在问，但google中并无答案，本文尝试从Mysql源码中寻找答案。

在Mysql中MVCC是在Innodb存储引擎中得到支持的，Innodb为每行记录都实现了三个隐藏字段：

6字节的事务ID（DB_TRX_ID ）

7字节的回滚指针（DB_ROLL_PTR）

隐藏的ID

6字节的事物ID用来标识该行所述的事务，7字节的回滚指针需要了解下Innodb的事务模型。

1. Innodb的事务相关概念

为了支持事务，Innbodb引入了下面几个概念：

redo log

redo log就是保存执行的SQL语句到一个指定的Log文件，当Mysql执行recovery时重新执行redo log记录的SQL *** 作即可。当客户端执行每条SQL（更新语句）时，redo log会被首先写入log buffer；当客户端执行COMMIT命令时，log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在，即Innodb的log文件。

undo log

与redo log相反，undo log是为回滚而用，具体内容就是copy事务前的数据库内容（行）到undo buffer，在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd数据文件中（表空间），即使客户端设置了每表一个数据文件也是如此。

rollback segment

回滚段这个概念来自Oracle的事物模型，在Innodb中，undo log被划分为多个段，具体某行的undo log就保存在某个段中，称为回滚段。可以认为undo log和回滚段是同一意思。

锁

Innodb提供了基于行的锁，如果行的数量非常大，则在高并发下锁的数量也可能会比较大，据Innodb文档说，Innodb对锁进行了空间有效优化，即使并发量高也不会导致内存耗尽。

对行的锁有分两种：排他锁、共享锁。共享锁针对对，排他锁针对写，完全等同读写锁的概念。如果某个事务在更新某行（排他锁），则其他事物无论是读还是写本行都必须等待；如果某个事物读某行（共享锁），则其他读的事物无需等待，而写事物则需等待。通过共享锁，保证了多读之间的无等待性，但是锁的应用又依赖Mysql的事务隔离级别。

隔离级别

隔离级别用来限制事务直接的交互程度，目前有几个工业标准：

- READ_UNCOMMITTED：脏读

- READ_COMMITTED：读提交

- REPEATABLE_READ：重复读

- SERIALIZABLE：串行化

Innodb对四种类型都支持，脏读和串行化应用场景不多，读提交、重复读用的比较广泛，后面会介绍其实现方式。

2. 行的更新过程

下面演示下事务对某行记录的更新过程：

1. 初始数据行

F1～F6是某行列的名字，1～6是其对应的数据。后面三个隐含字段分别对应该行的事务号和回滚指针，假如这条数据是刚INSERT的，可以认为ID为1，其他两个字段为空。

2.事务1更改该行的各字段的值

当事务1更改该行的值时，会进行如下 *** 作：

用排他锁锁定该行

简介：

大家好，我是xp，我又诈尸了

mvcc ，想必大家都不陌生，每个Java程序员都或多或少的了解过，不过不知道大家都是怎么学习的，是不是简单的百度一下呢？下面，我来带大家装个13，调试 mvcc 。咳，不是源码哈，但有那味了。

开卷开卷。

首先介绍一下 mvcc 的字面意思，全称： Multiversion Concurrency Control，翻译下来就是多版本并发控制技术。

脏读、 不可重复读 、幻读的概念就不多啰嗦了，mvcc具体的含义也不多啰嗦了，可以自行百度。 mvcc 解决了脏读、 不可重复读、部分幻读 ，包含了3个重要成分：

undo log作用：

在数据修改的时候，不仅记录了 redo log，还记录了 undo log 。但是 不同于 redo log， undo log 是逻辑日志。简单理解成， delete的时候，undo log会出现一条insert，update的时候，undo log会出现一条旧数据， 用来事务失败之后的回滚。

3个隐式字段：

Read View：

好了，理论讲完了，让我们嗨起来。

嗨之前，有一个情况单独说一下：

可以看到，此时的trx_id非常大，这是因为此时是只读事务。对于只读事务， InnoDB 并不会分配 trx_id，只有发生dml才会分配。这样有2个好处：

当commit了之后，我们使用SHOW ENGINE INNODB STATUS查看：

可以看到，显示该事务并没有开始。

好，回到正轨，相信大家都知道， 视图可见性判断（不知道的先百度 mvcc ）：

整体是这样的：

第一步我们以 38488 为开始值，把 name 更新成 111 ，并且 commit

第二步以 38490 把 name 更新成 222，333 ，但是不 commit

当 38490 第一次修改为 222 的时候，数据结构大致是这样的：

使用 SHOW ENGINE INNODB STATUS 侧面验证：

当 38490 第二次修改为 333 的时候，数据结构大致是这样的：

使用 SHOW ENGINE INNODB STATUS 侧面验证：

第三步以 38491 去查询，此时生成的 m_ids 应该是 [348490，38491]

使用 SHOW ENGINE INNODB STATUS 侧面验证：

此时 ReadView 的几个属性值为：

接下来我们来验证结论：

1：不用验证，当前事务修改的肯定自己可见

2： 38491查询id=1的记录，name为111

38488 <348490，所以111可见

3：不用验证，38492是下个事务的id，还没生成呢，当前事务，肯定看不见下个事务修改的值

4：我们先把38491commit，把id为20的name更新成111

然后再开一个事务38496：

此时查id为20，是可见的

m_ids：[348490，38496]，因为38491已经commit了，所以m_ids没有。此时的38491在m_ids之间，但是在m_ids里面找不到，所以可见。

好了，愉快的装13结束了，兄弟们，下次见。

比较常用的两种分别是读已提交、可重复读，那么Mysql是如何保证多个事务读取一条数据的隔离性的？

当我们读取一条被其他事务变更的数据时,会在undo Log中产生一条变更前的日志.这个日志可以专门用于回滚。

我们大概来看一下这个日志的大概结构:

前面三个字段属于变更前的，另外：

trx_id : 代表是哪个事务编号修改的。

roll_pointer : 相当于一个链表，往下查找就是上一次更改前的。当一条数据被更改了多次之后，由该字段构建成一个链表俗称 版本链 。

有了undo Log的话可以很快追溯到更改之前的数据，有了这个之后，假设多个事务都在读同一条记录，并且还发生了修改，这个时候

多版本并发控制，指的就是在使用读提交和可重复读隔离级别的事务，在执行普通select *** 作时，访问记录版本链的过程；使不同事务的读写、写读 *** 作并发执行，提高系统性能；

基于当前活跃事务列表构成的ReadView，当某个事务创建ReadView时，会将当前活跃的事务也加入其中。

我们来看一下大概结构：

readview 中四个比较重要的概念：

m_ids ：表示在生成readview时，当前系统中 活跃的读写事务id列表 ；

min_trx_id ：表示在生成readview时，当前系统中活跃的读写事务中最小的事务id，也就是m_ids中最小的值；

max_trx_id ：表示生成readview时，系统中应该分配给下一个事务的id值；

creator_trx_id ：表示生成该readview的事务的事务id；

有了readview，在访问某条记录时，按照以下步骤判断记录的某个版本是否可见:

下面是对于同一条数据的多个事务读取流程:

ReadView( 简称RV )一旦创建是不可变的，即便其中某个线程事务提交了，也不会影响当前线程创建的ReadView，你可以理解为一个副本快照。

总的来说判断就三个条件:

基于上述规则，很好的解决了一致性读的问题；当前线程创建完RV之后，读到的数据都是相同的；不会读到其他事务未提交和后提交的数据。

可重复读的RV是以一个事务的开始和结束作为它的生命周期的

读提交级别是能够读到其他事务提交的数据的，那么这个时候上面的流程是不是满足不了呀？因为假设ABC都在一个RV之中，C提交了数据，但是B看不到呀，因为条件2就满足不了呀；

这个时候Mysql就把这个级别的RV做了调整， 每次读取数据的时候会创建一个新的ReadView

当RV中的事务B提交了事务的时候，A每次会创建一个新的RV来查看数据版本，新的RV的m_ids肯定是不包含已经提交的事务B的，这个时候就能够读到事务B的数据了。

之前一直以为可重复读没有解决幻读的问题，现在基于这个流程另外加上命令行调试之后发现应该是解决了的。

因为一旦创建RV的话，当前活跃事务快照已经生成，这个时候如果新来的事务或者快照内的事务新增了数据也不会读到：

如有问题，欢迎留言交流。

---