(十)全解MySQL之死锁问题分析、事务隔离与锁机制的底层原理剖析

向右看齐 2023-10-03 21:01 4阅读 0赞

经过[《MySQL锁机制》][MySQL]、[《MySQL-MVCC机制》][MySQL-MVCC]两篇后，咱们已经大致了解`MySQL`中处理并发事务的手段，不过对于锁机制、`MVCC`机制都并未与之前说到的[《MySQL事务机制》][MySQL 1]产生关联关系，同时对于`MySQL`锁机制的实现原理也未曾剖析，因此本篇作为事务、锁、`MVCC`这三者的汇总篇，会在本章中补全之前空缺的一些细节，同时也会将锁、`MVCC`机制与事务机制之间的关系彻底理清楚。

### 一、MySQL中的死锁现象 ###

还记得咱们在[《MySQL锁机制》][MySQL]这篇文章中，描述事务、连接、线程三者关系的那段话嘛？

![format_png][]

所谓的并发事务，本质上就是`MySQL`内部多条工作线程并行执行的情况，也正由于`MySQL`是多线程应用，所以需要具备完善的锁机制来避免线程不安全问题的问题产生，但熟悉多线程编程的小伙伴应该都清楚一点，对于多线程与锁而言，存在一个`100%`会出现的偶发问题，**即死锁问题**。

#### 1.1、死锁问题概述（Dead Lock） ####

对于死锁的定义，这里就不展开叙述了，因为在之前[《并发编程-死锁、活锁、锁饥饿》][-]中曾详细描述过，如下：

![format_png 1][]

一句话来概述死锁：**死锁是指两个或两个以上的线程（或进程）在运行过程中，因为资源竞争而造成相互等待、相互僵持的现象**，一般当程序中出现死锁问题后，若无外力介入，则不会解除“僵持”状态，它们之间会一直相互等待下去，直到天荒地老、海枯石烂~

> 当然，为了照顾一些不想看并发编程文章的小伙伴，这里也把之前的死锁栗子搬过来~

> 某一天竹子和熊猫在森林里捡到一把玩具弓箭，竹子和熊猫都想玩，原本说好一人玩一次的来，但是后面竹子耍赖，想再玩一次，所以就把弓一直拿在自己手上，而本应该轮到熊猫玩的，所以熊猫跑去捡起了竹子前面刚刚射出去的箭，然后跑回来之后便发生了如下状况：  
> 熊猫道：竹子，快把你手里的弓给我，该轮到我玩了....  
> 竹子说：不，你先把你手里的箭给我，我再玩一次就给你....  
> 最终导致熊猫等着竹子的弓，竹子等着熊猫的箭，双方都不肯退步，结果陷入僵局场面.....

比如上述这个栗子中，「竹子、熊猫」可以理解成两条线程，而「弓、箭」则可以理解成运行时所需的资源，由于双方各自占据对方所需的资源，因此就造就了死锁现象发生，此时想要解决这个问题，就必须第三者外力介入，把“违反约定”的竹子手中的弓拿过去给熊猫......，然后等熊猫玩了之后，再给竹子，恢复之前原有的“执行顺序”。

#### 1.2、MySQL中的死锁现象 ####

而`MySQL`与`Redis、Nginx`这类单线程工作的程序不同，它属于一种内部采用多线程工作的应用，因而不可避免的就会产生死锁问题，比如举个例子：

SELECT * FROM `zz_account`;
    +-----------+---------+
    | user_name | balance |
    +-----------+---------+
    |    熊猫   | 6666666 |
    |    竹子   | 8888888 |
    +-----------+---------+
    
    -- T1事务：竹子向熊猫转账
    UPDATE `zz_account` SET balance = balance - 888 WHERE user_name = "竹子";
    UPDATE `zz_account` SET balance = balance + 888 WHERE user_name = "熊猫";
    
    -- T2事务：熊猫向竹子转账
    UPDATE `zz_account` SET balance = balance - 666 WHERE user_name = "熊猫";
    UPDATE `zz_account` SET balance = balance + 666 WHERE user_name = "竹子";
    复制代码

上面有一张很简单的账户表，因为只是为了演示效果，所以其中仅设计了用户名和余额两个字段，紧接着有`T1、T2`两个事务，`T1`中竹子向熊猫转账，而`T2`中则是熊猫向竹子转账，也就是一个相互转账的过程，此时来分析一下：

*  ①`T1`事务会先扣减竹子的账户余额，因此会修改数据，此时会默认加上排他锁。
 *  ②`T2`事务也会先扣减熊猫的账户余额，因此同样会对熊猫这条数据加上排他锁。
 *  ③`T1`减完了竹子的余额后，准备获取锁把熊猫的余额加`888`，但由于此时熊猫的锁被`T2`事务持有，`T1`会陷入阻塞等待。
 *  ④`T2`减完熊猫的余额后，也准备获取锁把竹子的余额加`666`，但此时竹子的锁被`T1`持有。

此时就会出现问题，`T1`等待`T2`释放锁、`T2`等待`T1`释放锁，双方各自等待对方释放锁，一直如此僵持下去，最终就引发了死锁问题，那先来看看具体的`SQL`执行情况是什么样的呢？如下：

![format_png 2][]

如上图所示，一步步的跟着标出的序号去看，最终会发现：当死锁问题出现时，`MySQL`会自动检测并介入，强制回滚结束一个“死锁的参与者（事务）”，从而打破死锁的僵局，让另一个事务能继续执行。

> 看到这里有小伙伴会问了，为啥`MySQL`能自动检测死锁呀？其实这跟死锁检测机制有关，后续再细说。

但是要牢记一点，如果你也想自己做上述实验，那么千万不要忘了在创建了表后，基于`user_name`创建一个主键索引：

ALTER TABLE `zz_account` ADD PRIMARY KEY p_index(user_name);
    复制代码

如果你不为`user_name`字段加上主键索引，那是无法模拟出死锁问题的，这是为什么呢？还记得之前在[《MySQL锁机制-记录锁》][MySQL_-]中聊到的一点嘛？在`InnoDB`中，如果一条`SQL`语句能命中索引执行，那就会加行锁，但如果无法命中索引加的就是表锁。

> 在上述给出的案例中，因为表中没有显示指定主键，同时也不存在一个唯一非空的索引，因此`InnoDB`会隐式定义一个`row_id`来维护聚簇索引的结构，但因为`update`语句中无法使用这个隐藏列，所以是走全表方式执行，因此就将整个表数据锁起来了。

而这里的四条`update`语句都是基于`zz_account`账户表在操作，因此两个事务竞争的是同一个锁资源，所以自然无法复现死锁现象，也就是`T1`修改时，`T2`的第一条`SQL`也不能执行，会阻塞等待表锁的释放。

> 而当咱们显示的定义了主键索引后，`InnoDB`会基于该主键字段去构建聚簇索引，因此后续的`update`语句可以命中索引，执行时自然获取的也是行级别的排他锁。

#### 1.3、MySQL中死锁如何解决呢？ ####

在之前关于死锁的并发文章中聊到过，对于解决死锁问题可以从多个维度出发，比如预防死锁、避免死锁、解除死锁等，而当死锁问题出现后该如何解决呢？一般只有两种方案：

*  锁超时机制：事务/线程在等待锁时，超出一定时间后自动放弃等待并返回。
 *  外力介入打破僵局：第三者介入，将死锁情况中的某个事务/线程强制结束，让其他事务继续执行。

1.3.1、MySQL的锁超时机制

在`InnoDB`中其实提供了锁的超时机制，也就是一个事务在长时间内无法获取到锁时，就会主动放弃等待，抛出相关的错误码及信息，然后返回给客户端。但这里的时间限制到底是多久呢？可以通过如下命令查询：

默认的锁超时时间是`50s`，也就是在`50s`内未获取到锁的事务，会自动结束并返回。那也就意味着当死锁情况出现时，这个死锁过程最多持续`50s`，然后其中就会有一个事务主动退出竞争，释放持有的锁资源，这似乎听起来蛮不错呀，但实际业务中，仅依赖超时机制去解除死锁是不够的，毕竟高并发情况下，`50s`时间太长了，会导致越来越多的事务阻塞。

> 那么咱们能不能把这个参数调小一点呢？比如调到`1s`，可以吗？当然可以，确实也能确保死锁发生后，在很短的时间内可以自动解除，但改掉了这个参数之后，也会影响正常事务等待锁的时间，也就是大部分未发生死锁，但需要等待锁资源的事务，在等待`1s`之后，就会立马报错并返回，这显然并不合理，毕竟容易误伤“友军”。

也正是由于依靠锁超时机制，略微有些不靠谱，因此`InnoDB`也专门针对于死锁问题，研发了一种检测算法，名为`wait-for graph`算法。

1.3.2、死锁检测算法 - wait-for graph

这种算法是专门用于检测死锁问题的，在该算法中会对于目前库中所有活跃的事务生成等待图，啥意思呢？以上述的死锁案例来看，在`MySQL`内部会生成一张这样的等待图：

![format_png 3][]

也就是`T1`持有着「竹子」这条数据的锁，正在等待获取「熊猫」这条数据的锁，而`T2`事务持有「熊猫」这条数据的锁，正在等待获取「竹子」这条数据的锁，最终`T1、T2`两个事务之间就出现了等待闭环，因此当`MySQL`发现了这种等待闭环时，就会强制介入，回滚结束其中一个事务，强制打破该闭环，从而解除死锁问题。

> 但这个“等待图”只是为了方便理解画出来的，内部的实现其实存在些许差异，一起来聊一聊。

`wait-for graph`算法被启用后，会要求`MySQL`收集两个信息：

*  锁的信息链表：目前持有每个锁的事务是谁。
 *  事务等待链表：阻塞的事务要等待的锁是谁。

每当一个事务需要阻塞等待某个锁时，就会触发一次`wait-for graph`算法，该算法会以当前事务作为起点，然后从「锁的信息链表」中找到对应中锁信息，再去根据锁的持有者（事务），在「事务等待链表」中进行查找，看看持有锁的事务是否在等待获取其他锁，如果是，则再去看看另一个持有锁的事务，是否在等待其他锁.....，经过一系列的判断后，再看看是否会出现闭环，出现的话则介入破坏。

> 上面这个算法的过程，听起来似乎有些晕乎乎的，但实际上并不难，套个例子来理解，好比目前库中有`T1、T2、T3`三个事务、有`X1、X2、X3`三个锁，事务与锁的关系如下：
> 
> ![format_png 4][]

此时当`T3`事务需要阻塞等待获取`X1`锁时，就会触发一次`wait-for graph`算法，流程如下：

*  ①先根据`T3`要获取的`X1`锁，在「锁的信息链表」中找到`X1`锁的持有者`T1`。
 *  ②再在「事务等待链表」中查找，看看`T1`是否在等待获取其他锁，此时会得知`T1`等待`X2`。
 *  ③再去「锁的信息链表」中找到`X2`锁的持有者`T2`，再看看`T2`是否在阻塞等待获取其他锁。
 *  ④再在「事务等待链表」中查找`T2`，发现`T2`正在等待获取`X3`锁，再找`X3`锁的持有者。

经过上述一系列算法过程后，最终会发现`X3`锁的持有者为`T3`，而本次算法又正是`T3`事务触发的，此时又回到了`T3`事务，也就代表着产生了“闭环”，因此也可以证明这里出现了死锁现象，所以`MySQL`会强制回滚其中的一个事务，来抵达解除死锁的目的。

> 但出现死锁问题时，`MySQL`会选择哪个事务回滚呢？之前分析过，当一个事务在执行`SQL`更改数据时，都会记录在`Undo-log`日志中，`Undo`量越小的事务，代表它对数据的更改越少，同时回滚的代价最低，因此会选择`Undo`量最小的事务回滚（如若两个事务的`Undo`量相同，会选择回滚触发死锁的事务）。

同时，可以通过`innodb_deadlock_detect=on|off`这个参数，来控制是否开启死锁检测机制。

> 死锁检测机制在`MySQL`后续的高版本中是默认开启的，但实际上死锁检测的开销不小，上面三个并发事务阻塞时，会对「事务等待链表、锁的信息链表」共计检索六次，那当阻塞的并发事务越来越多时，检测的效率也会呈线性增长。

1.3.3、如何避免死锁产生？

因为死锁的检测过程较为耗时，所以尽量不要等死锁出现后再去解除，而是尽量调整业务避免死锁的产生，一般来说可以从如下方面考虑：

*  合理的设计索引结构，使业务`SQL`在执行时能通过索引定位到具体的几行数据，减小锁的粒度。
 *  业务允许的情况下，也可以将隔离级别调低，因为级别越低，锁的限制会越小。
 *  调整业务`SQL`的逻辑顺序，较大、耗时较长的事务尽量放在特定时间去执行（如凌晨对账...）。
 *  尽可能的拆分业务的粒度，一个业务组成的大事务，尽量拆成多个小事务，缩短一个事务持有锁的时间。
 *  如果没有强制性要求，就尽量不要手动在事务中获取排他锁，否则会造成一些不必要的锁出现，增大产生死锁的几率。
 *  ........

其实简单来说，也就是在业务允许的情况下，尽量缩短一个事务持有锁的时间、减小锁的粒度以及锁的数量。

> 同时也要记住：当`MySQL`运行过程中产生了死锁问题，那这个死锁问题以后绝对会再次出现，当死锁被`MySQL`自己解除后，一定要记住去排除业务`SQL`的执行逻辑，找到产生死锁的业务，然后调整业务`SQL`的执行顺序，这样才能从根源上避免死锁产生。

### 二、锁机制的底层实现原理 ###

对于`MySQL`的锁机制究竟是如何实现的呢？对于这点其实很少有资料去讲到，一般都是停留在锁机制的表层阐述，比如锁粒度、锁类型的划分，但既然咱们讲了锁机制，那也就顺便聊一下它的底层实现。

#### 2.1、锁的内存结构 ####

在`Java`中，`Synchronized`锁是基于`Monitor`实现的，而`ReetrantLock`又是基于`AQS`实现的，那`MySQL`的锁是基于啥实现的呢？想要搞清楚这点，得先弄明白锁的内存结构，先看图：

![format_png 5][]

`InnoDB`引擎中，每个锁对象在内存中的结构如上，其中记录的信息也比较多，先全部理清楚后再聊聊锁的实现。

2.1.1、锁的事务信息

其中记录着当前的锁结构是由哪个事务生成的，记录的是指针，指向一个具体的事务。

2.1.2、索引的信息

这个是行锁的特有信息，对于行锁来说，需要记录一下加锁的行数据属于哪个索引、哪个节点，记录的也是指针。

2.1.3、锁粒度信息

这个略微有些复杂，对于不同粒度的锁，其中存储的信息也并不同，如果是表锁，其中就记录了一下是对哪张表加的锁，以及表的一些其他信息。

但如果锁粒度是行锁，其中记录的信息更多，有三个较为重要的：

*  `Space ID`：加锁的行数据，所在的表空间`ID`。
 *  `Page Number`：加锁的行数据，所在的页号。
 *  `n_bits`：使用的比特位，对于一页数据中，加了多少个锁（后续结合讲）。

2.1.4、锁类型信息

对于锁结构的类型，在内部实现了复用，采用一个`32bit`的`type_mode`来表示，这个`32bit`的值可以拆为`lock_mode、lock_type、rec_lock_type`三部分，如下：

![format_png 6][]

*  `lock_mode`：表示锁的模式，使用低四位。
    
     *  `0000/0`：表示当前锁结构是共享意向锁，即`IS`锁。
     *  `0001/1`：表示当前锁结构是排他意向锁，即`IX`锁。
     *  `0010/2`：表示当前锁结构是共享锁，即`S`锁。
     *  `0011/3`：表示当前锁结构是排他锁，即`X`锁。
     *  `0100/4`：表示当前锁结构是自增锁，即`AUTO-INC`锁。
 *  `lock_type`：表示锁的类型，使用低位中的`5~8`位。
    
     *  `LOCK_TABLE`：当第`5`个比特位是`1`时，表示目前是表级锁。
     *  `LOCK_REC`：当第`6`个比特位是`1`时，表示目前是行级锁。
 *  `rec_lock_type`：表示行锁的具体类型，使用其余位。
    
     *  `LOCK_ORDINARY`：当高`23`位全零时，表示目前是临键锁。
     *  `LOCK_GAP`：当第`10`位是`1`时，表示目前是间隙锁。
     *  `LOCK_REC_NOT_GAP`：当第`11`位是`1`时，表示目前是记录锁。
     *  `LOCK_INSERT_INTENTION`：当第`12`位是`1`时，表示目前是插入意向锁。
     *  `.....`：内部还有一些其他的锁类型，会使用其他位。
 *  `is_waiting`：表示目前锁处于等待状态还是持有状态，使用低位中的第`9`位。
    
     *  `0`：表示`is_waiting=false`，即当前锁无需阻塞等待，是持有状态。
     *  `1`：表示`is_waiting=true`，即当前锁需要阻塞，是等待状态。

OK~，上面分析了这一堆之后，看起来难免有些晕乎乎的，上个例子来理解一下：

> `00000000000000000000000100100011`

比如上面给出的这组`bit`，锁粒度、锁类型、锁状态是什么情况呢？如下：

![format_png 7][]

从上图中可得知，目前这组`bit`代表一个阻塞等待的行级排他临键锁结构。

2.1.5、其他信息

这个所谓的其他信息，也就是指一些用于辅助锁机制的信息，比如之前死锁检测机制中的「事务等待链表、锁的信息链表」，每一个事务和锁的持有、等待关系，都会在这里存储，将所有的事务、锁连接起来，就形成了上述的两个链表。

2.1.6、锁的比特位

与其说是锁的比特位，不如说是数据的比特位，好比举个例子：

SELECT * FROM `zz_student`;
    +------------+--------+------+--------+
    | student_id | name   | sex  | height |
    +------------+--------+------+--------+
    |          1 | 竹子   | 男   | 185cm  |
    |          2 | 熊猫   | 女   | 170cm  |
    |          3 | 子竹   | 男   | 182cm  |
    |          4 | 棕熊   | 男   | 187cm  |
    |          5 | 黑豹   | 男   | 177cm  |
    |          6 | 脑斧   | 男   | 178cm  |
    |          7 | 兔纸   | 女   | 165cm  |
    +------------+--------+------+--------+
    复制代码

学生表中有七条数据，此时就会形成一个比特数组：`000000000`，等等，似乎不对！明明只有七条数据，为啥会有`9`个比特位呢？因为行锁中，间隙锁可以锁定无穷小、无穷大这两个间隙，因此这组比特中，首位和末位即表示无穷小、无穷大两个间隙。

好比此时`T1`事务，对`ID=2、3、6`这三条数据加锁了，此时这个比特数组就会变为`001100100`，表示`T1`事务同时锁定了三条数据。而之前聊到的`n_bits`，它就会记录一下在这组比特中，多少条记录被上锁了。

#### 2.2、InnoDB的锁实现 ####

上面已经分析了`MySQL`的锁对象结构，接着来设想一个问题：

> 如果一个事务同时需要对表中的`1000`条数据加锁，会生成`1000`个锁结构吗？

如果这里是`SQL Server`数据库，那绝对会生成`1000`个锁结构，因为它的行锁是加在行记录上的，但`MySQL`锁机制并不相同，因为`MySQL`是基于事务实现的锁，啥意思呢？来看看：

*  ①目前对表中不同行记录加锁的事务是同一个。
 *  ②需要加锁的记录在同一个页面中。
 *  ③目前事务加锁的类型都是相同的。
 *  ④锁的等待状态也是相同的。

当上述四点条件被满足时，符合条件的行记录会被放入到同一个锁结构中，好比以上面的问题为例：

> 假设加锁的`1000`条数据分布在`3`个页面中，同时表中没有其他事务在操作，加的都是同一类型的锁。

此时依据上述的前提条件，那在内存中仅会生成三个锁结构，能够很大程度上减少锁结构的数量。总之情况再复杂，也不会像`SQL Server`般生成`1000`个锁对象，那样开销太大了！

#### 2.3、MySQL获取锁的过程 ####

当一个事务需要获取某个行锁时，首先会看一下内存中是否存在这条数据的锁结构，如果存在则生成一个锁结构，将其`is_waiting`对应的比特位改为`1`，表示目前事务在阻塞等待获取该锁，当其他事务释放锁后，会唤醒当前阻塞的事务，然后会将其`is_waiting`改为`0`，接着执行`SQL`。

实际上会发现这个过程并不复杂，唯一有些难理解的点就在于：事务获取锁时，是如何在内存中，判断是否已经存在相同记录的锁结构呢？还记得锁结构中会记录的一个信息嘛？也就是「锁粒度信息」，如果是表锁，会记录表信息，如果是行锁，会记录表空间、页号等信息。在事务获取锁时，就是去看内存中，已存在的锁结构的这个信息，来判断是否存在其他事务获取了锁。

> 拿表锁来说，当事务要获取一张表的锁时，就会根据表名看一下其他锁结构，有没有获取当前这张表的锁，如果已经获取，看一下已经存在的表锁和目前要加的表锁，是否会存在冲突，冲突的话`is_waiting=1`，反之`is_waiting=0`，而行锁也是差不多的过程。

释放锁的过程也比较简单，这个工作一般是由`MySQL`自己完成的，当事务结束后会自动释放，释放的时候会去看一下，内存中是否有锁结构，正在等待获取目前释放的锁，如果有则唤醒对应的线程/事务。

其实看下来之后大家会发现，`MySQL`的锁机制实现，与常规的锁实现有些不一样，一般的锁机制都是基于持有标识+等待队列实现的，而`MySQL`则是略微有些不一样。

### 三、事务隔离机制的底层实现 ###

对于事务隔离机制的底层实现，其实在前面的章节中简单聊到过，对于并发事务造成的各类问题，在不同的隔离级别实际上，是通过不同粒度、类型的锁以及`MVCC`机制来解决的，也就是调整了并发事务的执行顺序，从而避免了这些问题产生，具体是如何做的呢？先来看看`DBMS`中对各隔离级别的要求。

*  `RU`/读未提交级别：要求该隔离级别下解决脏写问题。
 *  `RC`/读已提交级别：要求该隔离级别下解决脏读问题。
 *  `RR`/可重复读级别：要求该隔离级别下解决不可重复读问题。
 *  `Serializable`/序列化级别：要求在该隔离级别下解决幻读问题。

虽然`DBMS`中要求在序列化级别再解决幻读问题，但在`MySQL`中，`RR`级别中就已经解决了幻读问题，因此`MySQL`中可以将`RR`级别视为最高级别，而`Serializable`级别几乎用不到，因为序列化级别中解决的问题，在`RR`级别中基本上已经解决了，再将`MySQL`调到`Serializable`级别反而会降低性能。

> 当然，`RR`级别下有些极端的情况，依旧会出现幻读问题，但线上`100%`不会出现，这点后续聊，先来看看各大隔离级别在`MySQL`中是如何实现的。

#### 3.1、RU（Read Uncommitted）读未提交级别的实现 ####

对于`RU`级别而言，从它名字上就可以看出来，该隔离级别下，一个事务可以读到其他事务未提交的数据，但同时要求解决脏写（更新覆盖）问题，那思考一下该怎么满足这个需求呢？先来看看不加锁的情况：

SELECT * FROM `zz_users` WHERE user_id = 1;
    +---------+-----------+----------+----------+---------------------+
    | user_id | user_name | user_sex | password | register_time       |
    +---------+-----------+----------+----------+---------------------+
    |       1 | 熊猫      | 女       | 6666     | 2022-08-14 15:22:01 |
    +---------+-----------+----------+----------+---------------------+
    
    -- ----------- 请按照标出的序号阅读代码！！！ --------------
    
    -- ①开启一个事务T1
    begin;
    
    -- ③修改 ID=1 的姓名为 竹子
    UPDATE `zz_users` SET user_name = "竹子" WHERE user_id = 1;
    
    -- ⑥提交T1
    commit;
    复制代码

-- ②开启另一个事务T2
    begin;
    
    -- ④这里可以读取到T1中还未提交的 竹子 记录
    SELECT * FROM `zz_users` WHERE user_id = 1;
    
    -- ⑤T2中再次修改姓名为 黑熊
    UPDATE `zz_users` SET user_name = "黑熊" WHERE user_id = 1;
    
    -- ⑦提交T2
    commit;
    复制代码

假设上述两个事务并发执行时，都不加锁，`T2`自然可以读取到`T1`修改后但还未提交的数据，但当`T2`再次修改`ID=1`的数据后，两个事务一起提交，此时就会出现`T2`覆盖`T1`的问题，这也就是脏写问题，而这个问题是不允许存在的，所以需要解决，咋解决呢？

> 写操作加排他锁，读操作不加锁！

还是上述的例子，当写操作加上排他锁后，`T1`在修改数据时，当`T2`再次尝试修改相同的数据，也要获取排他锁，因此`T1、T2`两个事务的写操作会相互排斥，`T2`就需要阻塞等待。但因为读操作不会加锁，因此当`T2`尝试读取这条数据时，自然可以读到数据。

> 来分析一下，因为写-写会排斥，但写-读不会排斥，因此也满足了`RU`级别的要求，即可以读到未提交的数据，但是不允许出现脏写问题。

最终经过这一系列的讲解后，能够得知`MySQL-RU`级别的实现原理，**即写操作加排他锁，读操作不加锁！**

#### 3.2、RC（Read Committed）读已提交级别的实现 ####

理解了`RU`级别的实现后，再来看看`RC`，`RC`级别要求解决脏读问题，也就是一个事务中，不允许读另一个事务还未提交的数据，咋实现呢？

> 写操作加排他锁，读操作加共享锁！

这样一想，似乎好像没问题，还是以之前的例子来说，因为`T1`在修改数据，所以会对`ID=1`的数据加上排他锁，此时`T2`想要获取共享锁读数据时，`T1`的排他锁就会排斥`T2`，因此`T2`需要等到`T1`事务结束后才能读数据。

> 因为`T2`需要等待`T1`结束后才能读，既然`T1`都结束了，那也就代表着`T1`事务要么回滚了，`T2`读上一个事务提交的数据；要么`T1`提交了，`T2`读`T1`提交的数据，总之`T2`读到的数据绝对是提交过的数据。

这种方式的确能解决脏读问题，但似乎也会将所有并发事务串行化，会导致`MySQL`整体性能下降，因此`MySQL`引入了一种技术，也就是上篇聊到的[《MVCC机制》][MySQL-MVCC]，在每次`select`查询数据时，都会生成一个`ReadView`快照，然后依据这个快照去选择一个可读的数据版本。

> 因此对于`RC`级别的底层实现，对于写操作会加排他锁，而读操作会使用`MVCC`机制。

但由于每次`select`时都会生成`ReadView`快照，此时就会出现下述问题：

-- ①T1事务中先读取一次 ID=1 的数据
    SELECT * FROM `zz_users` WHERE user_id = 1;
    +---------+-----------+----------+----------+---------------------+
    | user_id | user_name | user_sex | password | register_time       |
    +---------+-----------+----------+----------+---------------------+
    |       1 | 熊猫      | 女       | 6666     | 2022-08-14 15:22:01 |
    +---------+-----------+----------+----------+---------------------+
    
    -- ②T2事务中修改 ID=1 的姓名为 竹子 并提交
    UPDATE `zz_users` SET user_name = "竹子" WHERE user_id = 1;
    commit;
    
    -- ③T1事务中再读取一次 ID=1 的数据
    SELECT * FROM `zz_users` WHERE user_id = 1;
    +---------+-----------+----------+----------+---------------------+
    | user_id | user_name | user_sex | password | register_time       |
    +---------+-----------+----------+----------+---------------------+
    |       1 | 竹子      | 女       | 6666     | 2022-08-14 15:22:01 |
    +---------+-----------+----------+----------+---------------------+
    复制代码

此时观察这个案例，明明是在一个事务中查询同一条数据，结果两次查询的结果并不一致，这也是所谓的不可重复读的问题。

#### 3.3、RR（Repeatable Read）可重复读级别的实现 ####

在`RC`级别中，虽然解决了脏读问题，但依旧存在不可重复读问题，而`RR`级别中，就是要确保一个事务中的多次读取结果一致，即解决不可重复读问题，咋解决呢？两种方案：

*  ①查询时，对目标数据加上临键锁，即读操作执行时，不允许其他事务改动数据。
 *  ②`MVCC`机制的优化版：一个事务中只生成一次`ReadView`快照。

相较于第一种方案，第二种方案显然性能会更好，因为第一种方案不允许读-写、写-读事务共存，而第二种方案则支持读写事务并行执行，咋做到的呢？其实也比较简单：

> 写操作加排他锁，对读操作依旧采用`MVCC`机制，但`RR`级别中，一个事务中只有首次`select`会生成`ReadView`快照。

还是以这个场景为例，在`RC`级别中，会对于`T1`事务的每次`SELECT`都生成快照，因此当`T1`第二次查询时，生成的快照中就能看到`T2`修改后提交的数据。但在`RR`级别中，只有首次`SELECT`会生成快照，当第二次`SELECT`操作出现时，依旧会基于第一次生成的快照查询，所以就能确保同一个事务中，每次看到的数据都是相同的。

> 也正是由于`RR`级别中，一个事务仅有首次`select`会生成快照，所以不仅仅解决了不可重复读问题，还解决了幻读问题，举个例子：

-- 先查询一次用户表，看看整张表的数据
    SELECT * FROM `zz_users`;
    +---------+-----------+----------+----------+---------------------+
    | user_id | user_name | user_sex | password | register_time       |
    +---------+-----------+----------+----------+---------------------+
    |       1 | 熊猫      | 女       | 6666     | 2022-08-14 15:22:01 |
    |       2 | 竹子      | 男       | 1234     | 2022-09-14 16:17:44 |
    |       3 | 子竹      | 男       | 4321     | 2022-09-16 07:42:21 |
    |       4 | 猫熊      | 女       | 8888     | 2022-09-27 17:22:59 |
    |       9 | 黑竹      | 男       | 9999     | 2022-09-28 22:31:44 |
    +---------+-----------+----------+----------+---------------------+
    
    -- ①T1事务中，先查询所有 ID>=4 的用户信息
    SELECT * FROM `zz_users` WHERE user_id >= 4;
    +---------+-----------+----------+----------+---------------------+
    | user_id | user_name | user_sex | password | register_time       |
    +---------+-----------+----------+----------+---------------------+
    |       4 | 猫熊      | 女       | 8888     | 2022-09-27 17:22:59 |
    |       9 | 黑竹      | 男       | 9999     | 2022-09-28 22:31:44 |
    +---------+-----------+----------+----------+---------------------+
    -- ②T1事务中，再将所有 ID>=4 的用户密码重置为 1111
    UPDATE `zz_users` SET password = "1111" WHERE user_id >= 4;
    
    -- ③T2事务中，插入一条 ID=6 的用户数据
    INSERT INTO `zz_users` VALUES(6,"棕熊","男","7777","2022-10-02 16:21:33");
    -- ④提交事务T2
    commit;
    
    -- ⑤T1事务中，再次查询所有 ID>=4 的用户信息
    +---------+-----------+----------+----------+---------------------+
    | user_id | user_name | user_sex | password | register_time       |
    +---------+-----------+----------+----------+---------------------+
    |       4 | 猫熊      | 女       | 1111     | 2022-09-27 17:22:59 |
    |       6 | 棕熊      | 男       | 7777     | 2022-10-02 16:21:33 |
    |       9 | 黑竹      | 男       | 1111     | 2022-09-28 22:31:44 |
    +---------+-----------+----------+----------+---------------------+
    复制代码

此时会发现，明明`T1`中已经将所有`ID>=4`的用户密码重置为`1111`了，结果改完再次查询会发现，表中依旧存在一条`ID>=4`的数据：棕熊，而且密码未被重置，这似乎产生了幻觉一样。

> 如果是`RC`级别，因为每次`select`都会生成快照，因此会出现这个幻读问题，但`RR`级别中因为只有首次查询会生成`ReadView`快照，因此上述案例放在`RR`级别的`MySQL`中，`T1`看不到`T2`新增的数据，因此`MySQL-RR`级别也解决了幻读问题。

小争议：MVCC机制是否彻底解决了幻读问题呢？

先上定论，`MVCC`并没有彻底解决幻读问题，在一种奇葩的情况下依旧会出现问题，先来看例子：

-- 开启一个事务T1
    begin;
    -- 查询表中 ID>10 的数据
    SELECT * FROM `zz_users` where user_id > 10;
    Empty set (0.01 sec)
    复制代码

因为用户表中不存在`ID>10`的数据，所以`T1`查询时没有结果，再继续往下看。

-- 再开启一个事务T2
    begin;
    -- 向表中插入一条 ID=11 的数据
    INSERT INTO `zz_users` VALUES(11,"墨竹","男","2222","2022-10-07 23:24:36");
    -- 提交事务T2
    commit;
    复制代码

此时`T2`事务插入一条`ID=11`的数据并提交，此时再回到`T1`事务中：

-- 在T1事务中，再次查询表中 ID>10 的数据
    SELECT * FROM `zz_users` where user_id > 10;
    Empty set (0.01 sec)
    复制代码

结果很明显，依旧未查询到`ID>10`的数据，因为这里是通过第一次生成的快照文件在读，所以读不到`T2`新增的“幻影数据”，似乎没问题对嘛？接着往下看：

-- 在T1事务中，对 ID=11 的数据进行修改
    UPDATE `zz_users` SET `password` = "1111" where `user_id` = 11;
    
    -- 在T1事务中，再次查询表中 ID>10 的数据
    SELECT * FROM `zz_users` where user_id > 10;
    +---------+-----------+----------+----------+---------------------+
    | user_id | user_name | user_sex | password | register_time       |
    +---------+-----------+----------+----------+---------------------+
    |      11 | 墨竹      | 男       | 1111     | 2022-10-07 23:24:36 |
    +---------+-----------+----------+----------+---------------------+
    复制代码

嗯？！？？此时会发现，`T1`事务中又能查询到`ID=11`的这条幻影记录了，这是啥原因导致的呢？因为我们在`T1`中修改了`ID=11`的数据，在[《MVCC机制原理剖析》][MySQL-MVCC]中曾讲过`MVCC`通过快照检索数据的过程，这里`T1`根据原本的快照文件检索数据时，因为发现`ID=11`这条数据上的隐藏列`trx_id`是自己，因此就能看到这条幻影数据了。

> 实际上这个问题有点四不像，可以理解成幻读问题，也可以理解成是不可重复读问题，总之不管怎么说，就是`MVCC`机制存在些许问题！但这种情况线下一般不会发生，毕竟不同事务之间都是互不相知的，在一个事务中，不可能会去主动修改一条“不存在”的记录。

但如若你实在不放心，想要彻底杜绝任何风险的出现，那就直接将事务隔离级别调整到`Serializable`即可。

#### 3.4、Serializable序列化级别的实现 ####

前面已经将`RU、RC、RR`三个级别的实现原理弄懂了，最后再来看看最高的`Serializable`级别，在这个级别中，要求解决所有可能会因并发事务引发的问题，那怎么做呢？比较简单：

> 所有写操作加临键锁（具备互斥特性），所有读操作加共享锁。

由于所有写操作在执行时，都会获取临键锁，所以写-写、读-写、写-读这类并发场景都会互斥，而由于读操作加的是共享锁，因此在`Serializable`级别中，只有读-读场景可以并发执行。

### 四、事务与锁机制原理篇总结 ###

在本章中，实则更多的是对[《MySQL事务篇》][MySQL 1]、[《MySQL锁机制》][MySQL_-]、[《MySQL-MVCC机制》][MySQL-MVCC]的补充以及汇总，在本篇中补齐了`MySQL`死锁分析、锁实现原理、事务隔离机制原理等内容，也结合事务、锁、`MVCC`机制三者的知识点，彻底理清楚了`MySQL`不同隔离级别下的实现，最后做个简单的小总结：

*  RU级别：读操作不加锁，写操作加排他锁。
 *  RC级别：读操作使用`MVCC`机制，每次`SELECT`生成快照，写操作加排他锁。
 *  RR级别：读操作使用`MVCC`机制，首次`SELECT`生成快照，写操作加临键锁。

作者：竹子爱熊猫  
链接：https://juejin.cn/post/7156111610589741063  
来源：稀土掘金  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[MySQL]: https://juejin.cn/post/7153869469394305061
[MySQL-MVCC]: https://juejin.cn/post/7155359629050904584
[MySQL 1]: https://juejin.cn/post/7152765784299667487
[format_png]: https://img-blog.csdnimg.cn/img_convert/e276cb638bb82c621d9b92366563a854.webp?x-oss-process=image/format,png
[-]: https://juejin.cn/post/7040397716307836936#heading-12
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/edc777e4a9d0a16ae30d26c22df01f36.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/a39c535ca500289d77ea07507b02b61b.webp?x-oss-process=image/format,png
[MySQL_-]: https://juejin.cn/post/7153869469394305061#heading-15
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/1e910755f8a1c7344dd03fd44de120f0.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/3eaf4e92a229f0ca8b1ae704dee45dd9.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/aa5f2f0e18c3a5e4227294103239efd1.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/b082ce815299ceeca8f6f0b91af02d0e.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/3440374c6268a374d51d27c71857867b.webp?x-oss-process=image/format,png