MySQL优化（三）：MySQL 事务与锁详解

Myth丶恋晨 2023-02-22 07:45 40阅读 0赞

### 目录 ###

*  一、数据库的事务
 *   *  1.1 事务的典型场景
     *  1.2 事务的定义
     *  1.3 哪些存储引擎支持事务
     *  1.4 事务的四大特性
     *   *   *  （1）原子性(atomicity)
             *  （2）一致性(consistency)
             *  （3）隔离性(isolation)
             *  （4）持久性(durability)
     *  1.5 数据库何时用到事务
     *  1.6 事务并发会带来的问题
     *  1.7 SQL92 标准（4个隔离级别）
     *  1.8 MySQL InnoDB 对隔离级别的支持
     *  1.9 两大实现方案
     *   *  1.9.1 LBCC
         *  1.9.2 MVCC（多版本的并发控制）
         *   *   *  演示
                 *  小结
 *  二 、MySQL InnoDB 锁的基本类型
 *   *  2.1 共享锁
     *  2.2 排它锁
     *  2.3 意向锁
 *  三 、行锁的原理
 *   *  3.1 无索引的表
     *  3.2 有主键索引的表
     *  3.3 有唯一索引的表
 *  四 、锁的算法
 *   *  4.1 记录锁(Record Locks )
     *  4.2 间隙锁(Gap Locks )
     *  4.3 临键锁(Next-key Locks )
     *  4.4 小结：隔离级别的实现
     *   *  4.4.1 Read Uncommited
         *  4.4.2 Read Commited
         *  4.4.3 Repeatable Read
         *  4.4.4 Serializable

*  整理自网络资料

# 一、数据库的事务 #

[数据库的事务][Link 1]

## 1.1 事务的典型场景 ##

比如下单，会操作订单表，资金表，物流表等等，这个时候我们需要让这些操作都在一个事务里面完成。在金融的系统里面事务配置是很常见的，比如行内转账的这种操作，如果我们把它简单地理解为一个账户的余额增加，另一个账户的余额减少的情况（当然实际上要比这复杂），那么这两个动作一定是同时成功或者同时失败的。

## 1.2 事务的定义 ##

维基百科的定义：事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。  
这里面有两个关键点，第一个，它是数据库最小的工作单元，是不可以再分的。第二个，它可能包含了一个或者一系列的 DML 语句，包括 insert delete update。

## 1.3 哪些存储引擎支持事务 ##

InnoDB 支持事务，这个也是它成为默认的存储引擎的一个重要原因；另一个是 NDB。

## 1.4 事务的四大特性 ##

#### （1）原子性(atomicity) ####

事务是一个不可分割的整体，为了保证事务的总体目标，事务必须具有原子性，即当数据修改时，要么全执行，要么全不执行，即不允许事务部分地完成，避免了只执行这些操作的一部分而带来的错误。

原子性，在 InnoDB 中是通过  undo log 来实现的，它记录了数据修改之前的值（逻辑日志），一旦发生异常，就可以用 undo log 来实现回滚操作。

#### （2）一致性(consistency) ####

事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。这种一致性状态，包括数据库自身的完整性约束，和用户自定义的完整性。

以转账为例，假设甲和乙两者的钱加起来一共是5000，那么不管甲和乙之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这属于用户自定义的完整性。

#### （3）隔离性(isolation) ####

当两个以上事务并发执行时，为了保证数据的安全性，将事务进行隔离，事务之间相互独立。  
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。

#### （4）持久性(durability) ####

当事务提交或回滚后，数据库会持久化地保存数据。即便是在数据库系统遇到故障的情况下也不会丢失该修改。

持久性怎么实现呢？数据库崩溃恢复（crash-safe）是通过什么实现的？  
持久性是通过 redo log 来实现的，我们操作数据的时候，会先写到内存的 bufferpool 里面，同时记录 redo log，如果在刷盘之前出现异常，在重启后就可以读取 redo log  
的内容，写入到磁盘，保证数据的持久性。

原子性，隔离性，持久性，最后都是为了实现一致性。

## 1.5 数据库何时用到事务 ##

当执行这样一条更新语句的时候，产生了事务吗？

update student set sname = '猫老公 111' where id=1;

实际上，它自动开启了一个事务，并且提交了，所以最终写入了磁盘。

这个是开启事务的第一种方式，自动开启和自动提交。

InnoDB 里面有一个 autocommit 的参数（分成两个级别， session 级别和 global级别）。它的默认值是 ON。

show variables like 'autocommit';

autocommit 这个参数是什么意思呢？是否自动提交。如果它的值是 true/on 的话，我们在操作数据的时候，会自动开启一个事务，和自动提交事务。

否则，如果我们把 autocommit 设置成 false/off，那么数据库的事务就需要我们手动地去开启和手动地去结束。

手动开启事务也有几种方式，一种是用 begin；一种是用 start transaction。

那么怎么结束一个事务呢？我们结束也有两种方式，第一种就是提交一个事务，commit；还有一种就是 rollback，回滚的时候，事务也会结束。还有一种情况，客户端的连接断开的时候，事务也会结束。

## 1.6 事务并发会带来的问题 ##

1.脏读  
在一个事务处理过程中，读取到了另一个未提交的事务中的数据。

2.不可重复读  
不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改（或删除）并提交了。

3.幻读  
事务A读取某个范围的记录，事务B在该范围插入了新的记录，事务A再次读取该范围的记录，会产生幻行。

不可重复读和幻读说的都是读-读(注意是幻读，不是幻写)，只不过不可重复读是因为别的事务update(delete)而影响了两次select结果，幻读是因为别的事务insert而影响了两次select结果。

无论是脏读，还是不可重复读，或是幻读，它们都是数据库的 读一致性 的问题，都是在一个事务里面前后两次读取出现了不一致的情况。

读一致性的问题，必须要由数据库提供一定的事务隔离机制来解决。就像我们去饭店吃饭，基本的设施和卫生保证都是饭店提供的。我们使用数据库，隔离性的问题也必须由数据库帮助我们来解决。

## 1.7 SQL92 标准（4个隔离级别） ##

所以，就有很多的数据库专家联合制定了一个标准，也就是说建议数据库厂商都按照这个标准，提供一定的事务隔离级别，来解决事务并发的问题，这个就是 SQL92 标准。  
这个标准定义了数据库的4个隔离级别。

<table>  隔离级别对照表  
 <tbody> 
  <tr> 
   <td>事务隔离级别</td> 
   <td>脏读</td> 
   <td>不可重复读</td> 
   <td>幻读</td> 
  </tr> 
  <tr> 
   <td>未提交读（read-uncommitted）</td> 
   <td>是</td> 
   <td>是</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td>已提交读（read-committed）</td> 
   <td>否</td> 
   <td>是</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td>可重复读（repeatable-read）</td> 
   <td>否</td> 
   <td>否</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td>串行化（serializable）</td> 
   <td>否</td> 
   <td>否</td> 
   <td>否</td> 
  </tr> 
 </tbody> 
</table>

表中的“是”指的是当前隔离级别下，该问题是否会出现。  
隔离级别从上到下安全性越来越高，但是效率越来越低。

第一个隔离级别叫做：Read Uncommitted（未提交读），一个事务可以读取到其他事务未提交的数据，会出现脏读，所以叫做 RU，它没有解决任何的问题。

隔离级别叫做：Read Committed（已提交读），也就是一个事务**只能读取到其他事务已提交的数据**，不能读取到其他事务未提交的数据，它解决了脏读的问题，但是会出现不可重复读的问题。

第三个隔离级别叫做：Repeatable Read (可重复读)，它解决了不可重复读的问题，也就是**在同一个事务里面多次读取同样的数据结果是一样的**，但是在这个级别下，没有定义解决幻读的问题。

最后一个就是：Serializable（串行化），在这个隔离级别里面，所有的事务都是串行执行的，也就是对数据的操作需要排队，已经不存在事务的并发操作了，所以它解决了所有的问题。

这是 SQL92 的标准，但是不同的数据库厂商或者存储引擎的实现有一定的差异，比如 Oracle 里面就只有两种 RC（已提交读）和 Serializable（串行化）。那么 InnoDB的实现又是怎么样的呢？

## 1.8 MySQL InnoDB 对隔离级别的支持 ##

在 MySQL 的 InnoDB 里面，不需要使用串行化的隔离级别去解决所有问题。那我们来看一下 MySQL InnoDB 里面对数据库事务隔离级别的支持程度是什么样的。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70]

InnoDB 支持的四个隔离级别和 SQL92 定义的基本一致，隔离级别越高，事务的并发度就越低。唯一的区别就在于，InnoDB 在 RR 的级别就解决了幻读的问题 。这个也是InnoDB 默认使用 RR 作为事务隔离级别的原因，既保证了数据的一致性，又支持较高的并发度。

## 1.9 两大实现方案 ##

如果要解决读一致性的问题，保证一个事务中前后两次读取数据结果一致，实现事务隔离，应该怎么做？

总体上来说，我们有两大类的方案。

### 1.9.1 LBCC ###

第一种，既然要保证前后两次读取数据一致，那么读取数据的时候，锁定我要操作的数据，不允许其他的事务修改就行了。这种方案叫做**基于锁的并发控制** Lock BasedConcurrency Control（LBCC）。

如果仅仅是基于锁来实现事务隔离，一个事务读取的时候不允许修改，那就意味着不支持并发的读写操作，而我们的大多数应用都是读多写少的，这样会极大地影响操作数据的效率。

### 1.9.2 MVCC（多版本的并发控制） ###

另一种解决方案，如果要让一个事务前后两次读取的数据保持一致，那么我们可以**在修改数据的时候给它建立一个备份或者叫快照**，后面再来读取这个快照就行了。这种方案我们叫做**多版本的并发控制** Multi Version Concurrency Control（MVCC）。

问题：这个快照什么时候创建？读取数据的时候，怎么保证能读取到这个快照而不是最新的数据？怎么实现呢？

MVCC 的核心思想是： **可以查到在当前事务开始之前已经存在的数据，即使它在后面被修改或者删除了。在当前事务之后新增的数据，是查不到的。**

**InnoDB 为每行记录都实现了两个隐藏字段**：

**DB\_TRX\_ID**，6 字节：插入或更新行的最后一个事务的事务 ID，事务编号是自动递增的（我们把它理解为创建版本号，在数据新增或者修改为新数据的时候，记录当前事务 ID）。

**DB\_ROLL\_PTR**，7 字节：回滚指针（我们把它理解为删除版本号，数据被删除或记录为旧数据的时候，记录当前事务 ID）。

我们把这两个事务 ID 理解为版本号。

##### 演示 #####

下面进行演示：  
第一个事务，初始化数据（检查初始数据）：  
![在这里插入图片描述][20200702183931332.png]  
此时的数据，创建版本是当前事务 ID，删除版本为空：  
![在这里插入图片描述][20200702184018432.png]  
第二个事务，执行第 1 次查询，读取到两条原始数据，这个时候事务 ID 是 2：  
![在这里插入图片描述][20200702184037644.png]  
第三个事务，插入数据：  
![在这里插入图片描述][20200702184052593.png]  
此时的数据，多了一条 tom，它的创建版本号是当前事务编号，3：  
![在这里插入图片描述][20200702184107788.png]  
第二个事务，执行第 2 次查询：  
![在这里插入图片描述][20200702184124139.png]  
MVCC 的查找规则：只能查找创建时间**小于等于**当前事务 ID 的数据，和删除时间大  
于当前事务 ID 的行（或未删除）。

也就是不能查到在我的事务开始之后插入的数据，tom 的创建 ID 大于 2，所以还是  
只能查到两条数据。

第四个事务，删除数据，删除了 id=2 jack 这条记录：  
![在这里插入图片描述][20200702210737466.png]  
此时的数据，jack 的删除版本被记录为当前事务 ID，4，其他数据不变：  
![在这里插入图片描述][20200702210803801.png]  
在第二个事务中，执行第 3 次查询：  
![在这里插入图片描述][20200702212034694.png]  
查找规则：只能查找创建时间小于等于当前事务 ID 的数据，和删除时间大于当前事务 ID 的行（或未删除）。  
也就是在事务开始之后删除的数据，所以 jack 依然可以查出来。所以还是这两条数据。

第五个事务，执行更新操作，这个事务事务 ID 是 5：  
![在这里插入图片描述][2020070221231069.png]  
此时的数据，更新数据的时候，旧数据的删除版本被记录为当前事务 ID 5（undo），产生了一条新数据，创建 ID 为当前事务 ID 5：  
![在这里插入图片描述][20200702212330583.png]  
第二个事务，执行第 4 次查询：  
![在这里插入图片描述][20200702212348478.png]  
查找规则：只能查找创建时间小于等于当前事务 ID 的数据，和删除时间大于当前事务 ID 的行（或未删除）。

因为更新后的数据 penyuyan 创建版本大于 2，代表是在事务之后增加的，查不出来。

而旧数据 qingshan 的删除版本大于 2，代表是在事务之后删除的，可以查出来。

通过以上演示我们能看到，通过版本号的控制，无论其他事务是插入、修改、删除，第一个事务查询到的数据都没有变化。

##### 小结 #####

在 InnoDB 中，MVCC 是通过 Undo log 实现的。

Oracle、Postgres 等等其他数据库都有 MVCC 的实现。

需要注意，在 InnoDB 中，MVCC 和锁是协同使用，来实现隔离性的，这两种方案并不是互斥的。

第一大类解决方案是锁，锁又是怎么实现读一致性的呢？

# 二 、MySQL InnoDB 锁的基本类型 #

[官网][Link 2]把锁分成了 8 类。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 1]  
我们把前面的两个，行级别的锁（Shared and Exclusive Locks），和两个表级别的锁（Intention Locks）称为锁的基本模式。

后面三个 Record Locks、Gap Locks、Next-Key Locks，我们把它们叫做锁的算法，也就是分别在什么情况下锁定什么范围。

## 2.1 共享锁 ##

第一个**行级别**的锁就是我们在官网看到的 Shared Locks （共享锁），也叫S锁，我们获取了一行数据的读锁以后，可以用来读取数据，所以它也叫做读锁 。多个事务可以共享一把读锁（如果试衣间的门还没被锁上，顾客都能够同时进去参观，但是不能在里面涂鸦）。那怎么给一行数据加上读锁呢？

我们可以用 **select …… lock in share mode;** 的方式手工加上一把读锁。

只要事务结束，锁就会自动释放，包括提交事务和结束事务。

我们也来验证一下，看看共享锁是不是可以重复获取。

![在这里插入图片描述][202007022237281.png]  
SELECT … LOCK IN SHARE MODE走的是IS锁(意向共享锁)，即在符合条件的rows上都加了共享锁，这样的话，其他人可以读取这些记录，也可以继续添加IS锁，但是无法修改这些记录直到你这个加锁的过程执行完成(完成的情况有：事务的提交，事务的回滚，否则直接锁等待超时)。  
　　  
SELECT … LOCK IN SHARE MODE的应用场景适合于**两张表存在关系时的写操作**，拿mysql官方文档的例子来说，一个表是**child**表，一个是**parent**表。  
假设child表的某一列child\_id映射到parent表的c\_child\_id列，那么从业务角度讲，此时我直接insert一条child\_id=100记录到child表是存在风险的，因为刚insert的时候可能在parent表里删除了这c\_child\_id=100的记录，那么业务数据就存在不一致的风险。  
正确的方法是再插入时执行**select \* from parent where c\_child\_id=100 lock in share mode**,锁定了parent表的这条记录，然后执行insert into child(child\_id) values (100)就不会存在这种问题了。

## 2.2 排它锁 ##

二个**行级别**的锁叫做 Exclusive Locks（排它锁），也叫X锁，它是用来操作数据的，所以又叫做写锁。

**排他锁表示对数据进行写操作。如果一个事务对对象加了排他锁，其他事务就不能再给它加任何锁了**。(某个顾客把试衣间从里面反锁了，其他顾客想要使用这个试衣间，就只有等待锁从里面给打开了)

排它锁的加锁方式有两种，第一种是自动加排他锁：

我们在操作数据的时候，包括增删改，都会**默认**加上一个排它锁。

还有一种是手工加锁，我们用一个**FOR UPDATE** 给一行数据加上一个排它锁，这个无论是在我们的代码里面还是操作数据的工具里面，都比较常用。

select * from student where id=1 FOR UPDATE:

释放锁的方式跟前面是一样的。

排他锁的验证：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][20200704152953389.png]

## 2.3 意向锁 ##

意向锁 （Intention Locks，IS锁，有两种）是由数据库自己维护的。

当我们给一行数据加上共享锁之后，数据库会自动在这张表上面加一个**意向**共享锁。

当我们给一行数据加上排他锁之后，数据库会自动在这张表上面加一个**意向**排他锁。

反过来说：  
如果一张表上面至少有一个意向共享锁，说明有其他的事务给其中的某些数据行加上了共享锁。  
如果一张表上面至少有一个意向排他锁，说明有其他的事务给其中的某些数据行加上了排他锁。

这两个**表级别**的锁存在的意义是什么？

1.  我们有了表级别的锁，在 InnoDB里面就可以支持更多粒度的锁。
2.  如果说没有意向锁的话，当我们准备给一张表加上表锁的时候，是不是必须先要去判断有没其他的事务锁定了其中了某些行？如果有的话，肯定不能加上表锁。那么这个时候我们就要去扫描整张表才能确定能不能成功加上一个表锁，如果数据量特别大，比如有上千万的数据的时候，加表锁的效率是不是很低？  
    但是我们引入了意向锁之后就不一样了。只要判断这张表上面有没有意向锁，如果有，就直接返回失败。如果没有，就可以加锁成功。所以 InnoDB 里面的表锁，我们可以把它理解成一个标志。就像火车上厕所有没有人使用的灯，是用来提高加锁的效率的。

# 三 、行锁的原理 #

## 3.1 无索引的表 ##

若我们有三张表，一张**没有索引**的 t1，一张有**主键索引**的 t2，一张有**唯一索引**的t3。  
我们先假设 InnoDB 的锁，锁住了一行数据或者一条记录。  
我们先来看一下 t1 的表结构，它有两个字段，int 类型的 id 和 varchar 类型的 name。  
里面有 4 条数据，1、2、3、4。

现在我们在两个会话里面手工开启两个事务。  
在第一个事务里面，我们通过 where id =1 锁住第一行数据。  
在第二个事务里面，我们尝试给 id=3 的这一行数据加锁。

这个加锁的操作被阻塞了。为什么第一个事务锁住了 id=1 的这行数据，我却不能操作id=3 的数据呢？  
![在这里插入图片描述][20200704155333360.png]  
再来操作一条不存在的数据，插入 id=5。它也被阻塞了。实际上这里整张表都被锁住了。所以，我们的第一个猜想被推翻了，**InnoDB 的锁，锁住的不是 某条记录**。

为什么在没有索引或者没有用到索引的情况下，会锁住整张表？这个问题我们先留在这里。

## 3.2 有主键索引的表 ##

我们看一下 t2 的表结构。字段是一样的，不同的地方是 id 上创建了一个**主键索引**。里面的数据是 1、4、7、10。  
![在这里插入图片描述][20200704155656682.png]  
第一种情况，使用相同的 id 值去加锁，冲突；使用不同的 id 加锁，可以加锁成功。

那么，既然不是锁定一行数据，有没有可能是锁住了 id 的这个**字段**呢？

我们继续往下验证。

## 3.3 有唯一索引的表 ##

我们看一下 t3 的表结构。字段还是一样的， id 上创建了一个主键索引，name 上创建了一个唯一索引。里面的数据是 1、4、7、10。  
![在这里插入图片描述][20200704160141270.png]  
在第一个事务里面，我们通过 name 字段去锁定值是 4 的这行数据。  
在第二个事务里面，尝试获取一样的排它锁，肯定是失败的。  
在这里我们怀疑 InnoDB 锁住的是字段，所以换一个字段，用 id=4 去给这行数据加锁。又被阻塞了，说明锁住的是字段的这个推测也是错的，否则就不会出现第一个事务锁住了 name，第二个字段锁住 id 失败的情况。

既然锁住的不是 record，也不是 column，InnoDB 里面锁住的到底是什么呢？在这三个案例里面，我们要去分析一下他们的差异在哪里，也就是这三张表的结构，是什么区别导致了加锁的行为的差异？

其实答案就是索引。InnoDB 的行锁，就是通过锁住索引来实现的。

那么我们还有两个问题没有解决：  
**1、为什么表里面没有索引的时候，锁住一行数据会导致锁表？**  
或者说，如果锁住的是索引，一张表没有索引怎么办？

所以，一张表有没有可能没有索引？  
1）如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。  
2）如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引。  
3）如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐藏的聚集索引，它会随着行记录的写入而主键递增。

所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐藏的聚集索引都锁住了。

**2、为什么通过唯一索引给数据行加锁，主键索引也会被锁住？**  
在辅助索引里面，索引存储的是二级索引和主键的值。比如name=4，存储的是name的索引和主键 id 的值 4。

而主键索引里面除了索引之外，还存储了完整的数据。所以我们通过辅助索引锁定一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引，然后也锁定。

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

# 四 、锁的算法 #

![在这里插入图片描述][20200704162250116.png]  
现在讨论行锁的算法，也就是它锁住了什么范围？

t2 这张表有一个主键索引。  
我们插入了 4 行数据，主键 id 分别是 1、4、7、10。  
因为我们用主键索引加锁，我们这里的划分标准就是**主键索引**的值。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 4]  
这些数据库里面存在的主键值，我们把它叫做 Record，记录，那么这里我们就有 4个 Record。

根据主键，这些存在的 Record 隔开的数据不存在的区间，我们把它叫做 Gap，间隙，它是一个左开右开的区间。

假设我们有 N 个 Record，那么所有的数据会被划分成多少个 Gap 区间？答案是N+1，就像我们把一条绳子砍 N 刀，它最后肯定是变成 N+1 段。

最后一个，间隙（Gap）连同它右的记录（Record），我们把它叫做临键的区间，它是一个左开右闭的区间。

## 4.1 记录锁(Record Locks ) ##

第一种情况，**当我们对于唯一性的索引（包括唯一索引和主键索引）使用等值查询，精准匹配到一条记录**的时候，这个时候使用的就是**记录锁**。

select * from t2 where id=4 for update;

上面的语句执行后，id=4这条记录就会被锁住。

我们使用不同的 key 去加锁，不会冲突，它只锁住这个 record。

## 4.2 间隙锁(Gap Locks ) ##

第二种情况，**当我们查询的记录不存在，没有命中任何一个 record**，无论是用等值查询还是范围查询的时候，它使用的都是**间隙锁**。

举个例子，

select * from t2 where id >4 and id <7;
    select * from t2 where id = 6;

上面的任意一条语句执行后，（4，7）这个间隙就会被锁住。  
![在这里插入图片描述][20200704162724953.png]

select * from t2 where id >20 for update;

上面的语句执行后，（10，+∞）这个间隙就会被锁住。

![在这里插入图片描述][20200704164733908.png]  
注意，间隙锁主要是阻塞插入 insert。相同的间隙锁之间不冲突。

Gap Lock 只在 RR(可重复读) 中存在，如果要关闭间隙锁，就是把事务隔离级别设置成 RC（已提交读），并且把 innodb\_locks\_unsafe\_for\_binlog 设置为 ON。

## 4.3 临键锁(Next-key Locks ) ##

第三种情况，当我们使用了范围查询，不仅仅命中了 Record 记录，还包含了 Gap间隙，在这种情况下我们使用的就是**临键锁**，**它是 MySQL 默认的行锁算法，相当于记录锁加上间隙锁**。

唯一性索引，等值查询匹配到一条记录的时候，退化成记录锁。  
没有匹配到任何记录的时候，退化成间隙锁。  
其他情况用的都是临键锁。

比如我们使用>5 <9这个区间查询， 它包含了记录不存在的区间，也包含了一个 Record 7。  
![在这里插入图片描述][20200704165501967.png]  
![在这里插入图片描述][20200704165433800.png]  
临键锁，锁住最后一个 key 的当前区间和下一个左开右闭的区间。

select * from t2 where id >5 and id <=7 for update; -- 锁住(4,7]和(7,10]
    select * from t2 where id >8 and id <=10 for update; -- 锁住 (7,10]， (10,+∞)

为什么要锁住下一个左开右闭的区间？——就是为了解决**幻读**的问题。因为禁止了数据在区间的插入。

## 4.4 小结：隔离级别的实现 ##

所以，我们再回过头来看下这张图片，为什么 InnoDB 的 RR 级别能够解决幻读的问题，就是用临键锁实现的。  
下面对隔离级别的实现进行梳理。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 5]

### 4.4.1 Read Uncommited ###

RU 隔离级别：不加锁。

### 4.4.2 Read Commited ###

**已提交读**这个隔离级别下，普通的 select 都是快照读，使用 MVCC 实现。  
加锁的 select 都使用记录锁，因为**没有 Gap Lock**，所以 RC 会出现幻读的问题。。

除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会使用间隙锁封锁区间。

### 4.4.3 Repeatable Read ###

**可重复读**这个隔离级别下，普通的 select 使用快照读(snapshot read) ，底层使用 MVCC 来实现。

加锁的 select(select … in share mode / select … for update)以及更新操作update, delete 等语句使用当前读（current read），底层使用记录锁、或者间隙锁、临键锁 。

### 4.4.4 Serializable ###

Serializable （串行化）所有的 select 语句都会被隐式的转化为 select … **in share mode**，会和 update、delete 互斥。

[Link 1]: https://blog.csdn.net/z714405489/article/details/105363150
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200702135055969.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk=,size_16,color_FFFFFF,t_70
[20200702183931332.png]: https://img-blog.csdnimg.cn/20200702183931332.png
[20200702184018432.png]: https://img-blog.csdnimg.cn/20200702184018432.png
[20200702184037644.png]: https://img-blog.csdnimg.cn/20200702184037644.png
[20200702184052593.png]: https://img-blog.csdnimg.cn/20200702184052593.png
[20200702184107788.png]: https://img-blog.csdnimg.cn/20200702184107788.png
[20200702184124139.png]: https://img-blog.csdnimg.cn/20200702184124139.png
[20200702210737466.png]: https://img-blog.csdnimg.cn/20200702210737466.png
[20200702210803801.png]: https://img-blog.csdnimg.cn/20200702210803801.png
[20200702212034694.png]: https://img-blog.csdnimg.cn/20200702212034694.png
[2020070221231069.png]: https://img-blog.csdnimg.cn/2020070221231069.png
[20200702212330583.png]: https://img-blog.csdnimg.cn/20200702212330583.png
[20200702212348478.png]: https://img-blog.csdnimg.cn/20200702212348478.png
[Link 2]: https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200702215435764.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk=,size_16,color_FFFFFF,t_70
[202007022237281.png]: https://img-blog.csdnimg.cn/202007022237281.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200704152003861.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk=,size_16,color_FFFFFF,t_70
[20200704152953389.png]: https://img-blog.csdnimg.cn/20200704152953389.png
[20200704155333360.png]: https://img-blog.csdnimg.cn/20200704155333360.png
[20200704155656682.png]: https://img-blog.csdnimg.cn/20200704155656682.png
[20200704160141270.png]: https://img-blog.csdnimg.cn/20200704160141270.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200704161026887.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk=,size_16,color_FFFFFF,t_70
[20200704162250116.png]: https://img-blog.csdnimg.cn/20200704162250116.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200704161705767.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk=,size_16,color_FFFFFF,t_70
[20200704162724953.png]: https://img-blog.csdnimg.cn/20200704162724953.png
[20200704164733908.png]: https://img-blog.csdnimg.cn/20200704164733908.png
[20200704165501967.png]: https://img-blog.csdnimg.cn/20200704165501967.png
[20200704165433800.png]: https://img-blog.csdnimg.cn/20200704165433800.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200704170539925.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3MTQ0MDU0ODk=,size_16,color_FFFFFF,t_70