《MySQL中级系列教程-第十二章-彻底搞懂MVCC》

太过爱你忘了你带给我的痛 2022-09-08 00:14 167阅读 0赞

# 《MySQL中级系列教程-第十二章-彻底搞懂MVCC》 #

# 一、MVCC与LBCC #

## 1.1 MVCC介绍 ##

上一章我们说到了InnoDB在RR隔离级别下解决了幻读问题，又保证了高并发的读取（避免了串行化），那他到底是如何做的呢？

我们需要保证幻读，即保证前后两次读取的数据条数一致，那么我们就在我们读取的数据的时候加锁，锁定我们需要的数据，不允许其他事务对其修改；这种方案我们叫做基于锁的并发控制 Lock Based Concurrency Control（LBCC）。但很显然，InnoDB没有采用这种方案，我们在查询数据的时候并没有锁定行（没有加锁）；

从我们的直观理解上来看，要实现数据库的并发访问控制，最简单的做法就是LBCC，即读的时候不能写（允许多个线程同时读，即共享锁，S锁），写的时候不能读（一次最多只能有一个线程对同一份数据进行写操作，即排它锁，X锁）。这样的加锁访问，其实并不算是真正的并发，或者说它只能实现并发的读，因为它最终实现的是读写串行化，这样就大大降低了数据库的读写性能。加锁访问其实就是和MVCC相对的LBCC，即基于锁的并发控制（Lock-Based Concurrent Control），是四种隔离级别中级别最高的Serialize隔离级别。为了提出比LBCC更优越的并发性能方法，MVCC便应运而生。

MVCC（Multi-Version Concurrency Control）：多版本并发控制。并发访问（读或写）数据库时，对正在事务内处理的数据 **做多版本的管理**。以达到用来避免写操作的堵塞，从而引发读操作的并发问题。

MVCC实现了对数据库的并发访问，MVCC主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读；提高了数据库并发读写能力；

## 1.2 MVCC实现原理 ##

在InnoDB中，所有表中都会有三个隐藏的列，分别为：`DB_ROW_ID`、`DB_TRX_ID`、`DB_ROLL_PT`

*  `DB_TRX_ID`：**数据行版本号**；当有新的数据修改或插入时的事务ID号，用于记录修改这条记录的事务ID和创建这条记录的事务ID；
 *  `DB_ROLL_PTR`：**回滚指针**，也叫**删除行版本号**；指向`undo log`中这条记录的上一个版本，删除记录，记录当前事务ID；
 *  `DB_ROW_ID`：**聚集索引**；如果数据表没有主键，InnoDB会创建一个`DB_ROW_ID`作为聚集索引

**MVCC的目的就是实现数据库的并发读取**，为了解决读写冲突，它的实现原理主要是依赖记录中的**3个隐式字段，undo日志 ，Read View（快照）** 来实现的。

### 1.2.1 插入流程 ###

InnoDB在每次开启事务时都会为此次事务分配一个事务ID号，用于标识此次事务

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center]

本次事务插入的所有的数据行的版本号字段都为当前事务的ID；

### 1.2.2 删除流程 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center 1]

*  步骤：
    
     *  **①：将原来的数据copy一份，将新行的trx\_id设置为此次事务id**
     *  **②：将新的行的头信息中的delete\_flag标记为true，并将新行的roll\_id设置为旧行的trx\_id**

### 1.2.3 修改流程 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center 2]

*  步骤：
    
     *  **①：将原数据copy一份，并将当前行的trx\_id设置为此次事务id**
     *  **②：将新行的roll\_id设置为旧行的trx\_id**

### 1.2.4 查询流程 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center 3]

在MVCC中，查询时会拍下一个**一致性快照**（Read-View），该事务快照由查询时生成的所有事务id集合（trx\_ids）组成，trx\_ids中的事务id的大小范围为：`min_id<事务id<=max_id`；`min_id`为当前查询事务开启后的第一个事务id，`max_id`为此次查询事务提交前的最后一个事务id；

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center 4]

> tips：**在InnoDB中，MVCC只在RR和RC两个隔离级别下工作，因为RU隔离级别总是会读取最新的行，而不是符合当前事务版本的数据行。而Serializable则会对所有读取的行都加锁；**

以上的MVCC快照生成流程RC和RR隔离级别几乎一模一样，唯一不同的是生成 ReadView 的时机，**RR 级别只在事务开始时生成一次，之后一直使用该 ReadView。而 RC 级别则在每次 select 时，都会生成一个 ReadView；**

#### 1）RR环境下MVCC查询流程 ####

*  1、被查询的行记录中的`trx_id`为当前查询的`trx_id`（说明自己创建的）；
 *  2、被查询的行记录中的`trx_id`比事务快照中最小的还小，表明该记录为之前提交的，能够被当前事务访问（图中绿色部分）；
 *  3、被查询的行记录的`trx_id`大于等于`ReadView`中的`min_id`值，表明生成该版本的事务在当前事务生成`ReadView`后才开启，所以该版本**不可以被当前事务访问**（黄色部分）。

> **在进行判断时，首先会拿记录的最新版本来比较，如果该版本无法被当前事务看到，则通过记录的 DB\_ROLL\_PTR 找到上一个版本，重新进行比较，直到找到一个能被当前事务看到的版本。**

#### 2）RC环境下MVCC查询流程 ####

我们刚刚了解到，RC的查询流程和RR的是一样的；RC与RR唯一的不同点在于`ReadView`生成的次数，RR只在事务开始时生成一次，RC则是在每次select语句时都生成一次；也就是说每次select的时候trx\_ids都是在变化的（前提是有新的事务开启了）

## 1.3 快照读和当前读 ##

我们根据Undo日志的工作原理可以分析，当一个事务对表的任何的更新操作都会事先记录到Undo日志，当另一个事务查询的上一个事务的操作的那条数据时，返回的是当前事务的快照，也就是Undo日志中的记录；**我们把这种读取也称之为快照读取；**

**当前读**：即读的必须是当前最新的数据，当前读在每次读取都加上了锁，例如S锁（lock in share mode）、X锁（for update）等，当前读用于读取的是数据最新的版本，但当前读会对记录加锁，在事务并发访问情况下，如果其他事务对该记录加上了排它锁，那么当前读进入阻塞状态；同样的如果使用当前读读取数据，该数据也不能被其他事务加上排它锁；

**快照读**：在InnoDB事务中默认的读取方式就是快照读，即：`select * from user [where xxx];`这些操作默认都不会加锁的，这些操作读的都是数据的快照；快照读的出现极大的提升了InnoDB在并发读写能力上的提升；但由于快照读所读取的数据都是快照（旧版本数据），所以说快照读取并不一定是最新版本的数据；

我们来看一个案例：

<table> 
 <thead> 
  <tr> 
   <th>session-01</th> 
   <th>session-02</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>begin;</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td></td> 
   <td>begin;</td> 
  </tr> 
  <tr> 
   <td>select * from user where id=1; – age=18 (快照读)</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td></td> 
   <td>update user set age=20 where id=1;</td> 
  </tr> 
  <tr> 
   <td>select * from user where id=1; – age=18（快照读，保证读已提交）</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td></td> 
   <td>commit;</td> 
  </tr> 
  <tr> 
   <td>select * from user where id=1; – age=18（快照读，保证可重复读）</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>select * from user where id=1 lock in share mode; – age=20（当前读，读的是最新的版本）</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>commit/rollback;</td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

需要注意的是，当前读读的是最新的数据，但与此同时，id=1的这行记录已经被加上S锁了，其他事务要对其update（加X锁）就会被其阻塞，并发能力差；

> Tips：**快照读的前提是隔离级别不是串行化级别，串行化级别下的快照读会退化成当前读；**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center]: /images/20220829/05572f83c07e41cea36944e6cc7b39af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center 1]: /images/20220829/99ae8dedc2264abdb00ce227bcf150ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center 2]: /images/20220829/cea2f0f44ed7475fa25a71001bc8deb6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center 3]: /images/20220829/c31007d92d7b480ba81196b8cd0d0119.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA57eR5rC06ZW35rWBKno_size_25_color_dae8fc_t_70_pic_center 4]: /images/20220829/55062427e43d44aaaf03f3f2e8ddc437.png