深入简出的掌握InnoDB引擎 MVCC协议

本是古典何须时尚 2022-05-11 09:42 131阅读 0赞

MVCC（Multi-Version Concurrent Control），即多版本并发控制协议，广泛使用于数据库系统(mysql、HBase)。由于MVCC没有一个统一的实现标准，本人将针对mysql的InnoDB引擎谈谈它的应用。

**目录**

1. 概述

2. 产生背景

3.与事务隔离级别的关联

4. 原理

4.1 redo日志

4.2 undo日志

4.3 回滚段

4.4 行记录数据结构

5. 优缺点

6. 快照读 & 非快照读

7. 为什么select count(\*)在myisam表上很快,而在Innodb的表上很慢?

8. 能禁用MVCC吗?

--------------------

## 1. 概述 ##

MVCC（也叫快照读）是**行锁**的一种变种，但是他在很多情况下避免了加锁的操作，因此开销更低。多版本并发控制实现了**非阻塞**的读操作，也可称之为**一致性非锁定读**。它通过行的**多版本控制方式**来读取当前执行时间数据库中的行数据。实质上使用的是**快照数据（undo log中的行就是MVCC中的多版本）**。

## 2. 产生背景 ##

[InnoDB并发控制][InnoDB]之前讲过，总体的思路大概是：

*  **普通锁**，本质是串行执行
 *  **读写锁**，可以实现读读并发
 *  **数据多版本**，可以实现读写（修改）并发

## 3.与事务隔离级别的关联 ##

<table> 
 <tbody> 
  <tr> 
   <td style="width:249px;"><strong>读已提交（Read Committed）</strong></td> 
   <td style="width:600px;"> <p>在该级别下，<strong>每次select时，</strong>都会通过MVCC获取当前数据的最新快照（<strong>总是读取被锁定行的最新的快照数据</strong>），不加任何锁，也无视任何锁，</p> <p><span style="color:#f33b45;">它最大的问题就是不可重复的</span></p> </td> 
  </tr> 
  <tr> 
   <td style="width:249px;"><strong>可重复读（Repeatable Read）</strong></td> 
   <td style="width:600px;"> <p>在该级别下，MVCC版本的生成时间，事务中只在<strong>第一次select时</strong>生成版本（<strong>总是读取事务开始时的行数据版本</strong>），后续的查询都是在这个版本上进行</p> <p><span style="color:#f33b45;">它最大的问题就是幻读</span></p> </td> 
  </tr> 
 </tbody> 
</table>

> 不可重复读的重点是**修改**：同样的条件的select, 你读取过的数据, 再次读取出来发现值不一样了
> 
> 幻读的重点在于**新增或者删除**：同样的条件的select, 第1次和第2次读出来的记录数不一样，在行锁的基础上，加上Gap Lock，从而形成Next-Key Lock。[另一篇中重点介绍][InnoDB]

## 4. 原理 ##

1.  写任务发生时（修改时），将数据克隆一份，以版本号区分；
2.  写任务操作新克隆的数据，直至提交；
3.  并发读任务可以继续读取旧版本的数据，不至于阻塞；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70][]

1.  最开始数据的版本是V0；
2.  T1时刻发起了一个写任务，这是把数据clone了一份，进行修改，版本变为V1，但任务还未完成；
3.  T2时刻并发了一个读任务，依然可以读V0版本的数据；
4.  T3时刻又并发了一个读任务，依然不会阻塞；

可以看到，数据多版本，通过“读取旧版本数据”能够极大提高任务的并发度。

**这里有一个误区：**

>  *  每行数据都存在一个版本，每次数据更新时都更新该版本
>  *  修改时Copy出当前版本随意修改，各个事务之间无干扰
>  *  保存时比较版本号，如果成功（commit），则覆盖原记录；失败则放弃copy（rollback）

**啥？听起来含有乐观锁的味道，那你就大错特错了，而Innodb的真实实现是这样的：**

> 本质的在于当修改数据时是否要排他锁定，如果锁定了还算不算是MVCC？
> 
> Innodb的实现真算不上MVCC，因为并没有实现核心的多版本共存，undo log中的内容只是串行化的结果，记录了多个事务的过程，不属于多版本共存。但理想的MVCC是难以实现的，当事务仅修改一行记录使用理想的MVCC模式是没有问题的，可以通过比较版本号进行回滚；但当事务影响到多行数据时，理想的MVCC据无能为力了。
> 
>  *  事务以排他锁的形式修改原始数据（读除外）
>  *  把修改前的数据存放于undo log，通过回滚指针与主数据关联
>  *  修改成功（commit）啥都不做，失败则恢复undo log中的数据（rollback）

### **4.1 redo日志** ###

**一句话**，redo日志用于保障，已提交事务的ACID特性。假如某一时刻，数据库崩溃，还没来得及刷盘的数据，在数据库重启后，会重做redo日志里的内容，以保证已提交事务对数据产生的影响都刷到磁盘上。

**为什么要有redo****日志？**

数据库事务提交后，必须将更新后的数据刷到磁盘上，以保证ACID特性。磁盘**随机写**性能较低，如果每次都刷盘，会极大影响数据库的吞吐量。

优化方式是，将修改行为先写到redo日志里（此时变成了**顺序写**），再定期将数据刷到磁盘上，这样能极大提高性能。***随机写优化为顺序写**，思路更重要。*

### **4.2 undo日志** ###

**一句话**，undo日志用于保障，未提交事务不会对数据库的ACID特性产生影响。

**为什么要有undo****日志？**

数据库事务未提交时，会将事务修改数据的镜像（即修改前的旧版本）存放到undo日志里，当事务回滚时，或者数据库奔溃时，可以利用undo日志，即旧版本数据，撤销未提交事务对数据库产生的影响。

> *对于**insert操作**，undo日志记录新数据的PK(ROW\_ID)，回滚时直接删除；*
> 
> *对于**delete/update操作**，undo日志记录旧数据row，回滚时直接恢复；*
> 
> *他们分别存放在不同的buffer里。*

### **4.3 回滚段** ###

存储undo日志的地方，是回滚段。undo日志和回滚段和InnoDB的MVCC密切相关。

/**
     * t(id PK, name);
     * 数据为：
     * 1, shenjian
     * 2, zhangsan
     * 3, lisi
    **/
    --事务T1：
    start trx;
    delete (1, shenjian);
    update set(3, lisi) to (3, xxx);
    insert (4, wangwu);

事务T1（未执行前），没有事务，故回滚段是空的（下图）

![20190221213700700.png][]

事务T1执行，并且事务处于未提交的状态（下图）

![20190221213819349.png][]

假设事务提交，回滚段里的undo日志可以删除。

假如事务rollback，此时可以通过回滚段里的undo日志回滚（下图1），直至成功（下图2）。

![20190221214006896.png][]

![20190221214028132.png][]

这里提问一个问题：**旧版本数据存储在哪里？存储旧版本数据，对MySQL****和InnoDB****原有架构是否有巨大冲击？**

通过上文undo日志和回滚段的铺垫，旧版本数据存储在回滚段里，这样对对MySQL和InnoDB原有架构体系冲击不大。

### **4.4 行记录数据结构** ###

InnoDB的内核，会为每一行数据增加三个内部属性：

<table> 
 <tbody> 
  <tr> 
   <td style="width:130px;">DATA _TRX_ID</td> 
   <td>6字节，记录每一行最近一次修改它的事务ID（每开启一个<strong>新的事务</strong>，其对应的事务id会自动递增）</td> 
  </tr> 
  <tr> 
   <td style="width:130px;">DATA_ROLL_PTR</td> 
   <td>7字节，一个<strong>指向此条记录项的undo信息的指针</strong>，undo信息是指此条记录被修改前的信息；</td> 
  </tr> 
  <tr> 
   <td style="width:130px;">DB_ROW_ID</td> 
   <td>6字节，单调递增的行ID</td> 
  </tr> 
 </tbody> 
</table>

当读取一行记录时会进入下面流程：

![70][]

## 5. 优缺点 ##

*  优点：回滚段里的数据，其实是历史数据的快照（snapshot），这些数据是不会被修改，select可以肆无忌惮的并发读取他们。这种**一致性不加锁的读**（Consistent Nonlocking Read），就是InnoDB**并发如此之高**的核心原因之一。
 *  缺点：为了实现多版本,innodb必须对每行**增加相应的字段来存储版本信息**,同时需要维护每一行的版本信息,而且在**检索行的时候**,需要进行版本的比较,因而降低了查询的效率;innodb还必须**定期清理**不再需要的行版本,及时回收空间,这也增加了一些开销

## 6. **快照读 & 非快照读** ##

**快照读（Snapshot read）**

普通的select语句都是**快照读**，例如：select \* from t where id>2;

**非快照读**或叫**当前读（current read）**

显示加锁（前两种锁定读），这就复杂了可能是行锁、间隙锁、**Next-Key锁**，[另一篇中重点介绍][InnoDB]，例如：

select \* from table where ? lock in share mode; （加S锁）  
select \* from table where ? for update; （加X锁）  
insert, update, delete 操作前会先进行一次当前读（加X锁）

注：这两种锁都必须处于事务中，事务commit，锁释放。所以必须begin或者start transaction 开启一个事务或者索性set autocommit=0把自动提交关掉（mysql默认是1，即执行完sql立即提交）

## 7. 为什么select count(\*)在myisam表上很快,而在Innodb的表上很慢? ##

因为innodb采用了MVCC技术,对于相同的行,可能同时存在多个版本,innodb必须根据查询的时间来过滤掉一些行,才能得出结果,必然要执行全表扫描,而全表扫描是非常耗时的.对于myisam的表,任何行都只有一个版本,mysql甚至不需要扫描就可以直接返回精确的统计结果,我们用explain也可以看到,对于myisam的表,执行select count(\*)的时候,mysql显示” Select tables optimized away”,查询直接被优化了;而对于innodb的表,可能是全表扫描,也可能是”using index”,总之,速度肯定会比myisam的表慢很多。

你想了解的更多，参考我另一篇[索引底层原理][Link 1]

## 8. **能禁用MVCC吗?** ##

禁用MVCC可以降低innodb引擎的开销,而同时innodb又可以支持外键约束,可以实现自动恢复.MVCC本身不支持read uncommitted等级,所以可以通过设置transaction\_isolation = read uncommitted 来禁用MVCC.但是任何改变innodb默认隔离等级的操作,都会起到innodb\_locks\_unsafe\_for\_binlog=off类似的效果,这会导致诸如insert into t select \* from t\_src 之类的语句不再给源表t\_src加锁,也不再使用innodb的间隙锁,从而产生幻读,直接导致binlog中记录的sql语句不能正确的串行化,从而主从数据库的数据不再一致,而且基于binlog的增量备份也不再有效.所以除非不需要记录binlog,否则别这么做.当然我们可以这样做来优化从库的性能,因为从库不需要记录binlog.![InnoDB][]

**引用资源**

*  [how-does-mvcc-multi-version-concurrency-control-work][]
 *  [PostgreSQL Concurrency with MVCC][]

[InnoDB]: /images/20220511/3bdd536dd5294d99ba79b0af4f12131a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70]: /images/20220511/5ad27c112d0745e8aa3f40ad5868cc0c.png
[20190221213700700.png]: /images/20220511/fc9ab65455184bf398a5467d959b4bf5.png
[20190221213819349.png]: /images/20220511/4718525cebd9450698996182356401aa.png
[20190221214006896.png]: /images/20220511/da888c7d6b9e4aed86f30061cf433339.png
[20190221214028132.png]: /images/20220511/d944d03725fd4d7a8dd51c24de26fb86.png
[70]: /images/20220511/710194e956314209a32547ab65432a66.png
[Link 1]: https://blog.csdn.net/alex_xfboy/article/details/82818753
[how-does-mvcc-multi-version-concurrency-control-work]: https://vladmihalcea.com/how-does-mvcc-multi-version-concurrency-control-work/
[PostgreSQL Concurrency with MVCC]: https://devcenter.heroku.com/articles/postgresql-concurrency