【MySQL-25】万字总结＜锁＞——(全局锁＆行级锁＆表级锁)【共享锁，排他锁】【间隙锁，临键锁】【表锁，元数据锁，意向锁】

前言

大家好吖，欢迎来到 YY 滴MySQL系列 ，热烈欢迎！ 本章主要内容面向接触过C++的老铁
主要内容含：

欢迎订阅 YY滴C++专栏！更多干货持续更新！以下是传送门！

• YY的《C++》专栏
• YY的《C++11》专栏
• YY的《Linux》专栏
• YY的《数据结构》专栏
• YY的《C语言基础》专栏
• YY的《单片机》专栏
• YY的《STM32》专栏
• YY的《数据库》专栏

※锁的总结（前瞻）

一.锁的概述＆分类

二.全局锁

1.全局锁的基本概念＆画图演示

1. 场景： 备份过程中，其他业务干涉，导致数据不一致
2. 全局锁的目的： 保护数据一致性

• 全局锁就是对整个数据库实例加锁，加锁后整个实例就处于 只读状态，后续的DML的写语句，DDL语句， 已经更新操作的事务提交语句都将被阻塞 。
• 其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性

• 逻辑备份前加上 全局锁
• 逻辑备份后，解锁
  

三.行级锁

行级锁的基本概念＆分类（行锁 = 临键锁-见隙锁）

• 行级锁，每次操作锁住对应的行数据。锁定粒度最小， 发生锁冲突的概率最低 ，并发度最高应用在Inn0DB存储引擎中。
• InnoDB的数据是 基于索引组织的 ，行锁是通过对索引上的索引项加锁来实现的， 而不是对记录加的锁 。

对于行级锁，主要分为以下三类:

1. 行锁(Record Lock) ：锁定单个行记录的锁，防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。
   

• 表达：行锁=临键锁-见隙锁
  

2. 见隙锁(Gap Lock) ：锁定索引记录间隙(不含该记录) 确保索引记录间随不变，防止其他事务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。
   

• 表达：GAP
  

3. 临键锁(Next-KeyLock) ： 行锁和 它之前的 间隙锁组合 ，同时锁住数据，并锁住数据前面的间隙Gap。在RR隔离级别下支持。
   

• 表达：S
  

【1】【行锁】（共享锁，排他锁）

1.共享锁，排他锁机制介绍

InnoDB实现了以下两种类型的行锁:

1. 共享锁(S)： 允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁。 （共享锁之间是兼容的 ，共享锁与排他锁互斥）
2. 排他锁(X)： 允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。 （一个数据有了排他锁，就与其他共享锁和排他锁互斥）

2.不同SQL下，行锁的情况

• 分成两种，一种是增删改；另一种是查询
  

3.演示行锁

默认情况下，InnODB在 REPEATABLE READ事务隔离级别运行，InnoDB使用 临键锁 进行搜索和索引扫描，以防止幻读。（本次演示）

1. 针对 唯一索引 进行检索时，对已存在的记录进行等值匹配时，将会 自动优化为行锁

2. 不通过索引条件检索数据(InnoDB的行锁是针对于索引加的锁)，那么InnoDB将对表中的所有记录加锁，此时 就会升级为表锁

可以通过以下SOL，查看意向锁及行锁的加锁情况:

select object schema,object name,index name,lock type,lock mode,lock data from performance schema.data locks;

【1】情况1

演示：

• 我们查看一张表，发现表的id是 主键索引

• 我们加入共享锁

• 我们查看行锁的加锁情况: 注：TABLE 为表锁 RECORD为行锁
• 查看查看意向锁及行锁的加锁情况:

select object schema,object name,index name,lock type,lock mode,lock data from performance schema.data locks;

• 发现有共享锁S，且无间隙锁 REC_NOT_GAP

• 我们在另一客户端再加上共享锁，依旧能执行；因为 （共享锁之间是兼容的 ，共享锁与排他锁互斥）

【2】情况2

不通过索引条件检索数据(InnoDB的行锁是针对于索引加的锁)，那么InnoDB将对表中的所有记录加锁，此时 就会升级为表锁
演示：

• 有这么一张表，为主键索引
  
• 我们针对非索引条件检索数据name，进行更新操作
• 此时行锁就会升级成表锁
  
• 此时我们再开一个终端，对id=3的数据行进行修改，发现进入阻塞状态
  

【2】【临键锁S】【间隙锁】演示

※【临键锁S】【间隙锁】特性演示目录

下面进行演示：

默认情况下，InnODB在 REPEATABLE READ事务隔离级别运行，InnoDB使用 next-key锁进行搜索和索引扫描，以防止幻读。

1. 索引上的等值查询 (唯一索引，例如主键索引) ，给 不存在的记录 加锁时,优化为间隙锁。
2. 索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止。
3. 索引上的等值查询(普通索引)，向右遍历时最后一个值不满足查询需求时，next-key lock 退化为间隙锁。

1.演示：索引上的等值查询 (唯一索引，例如主键索引)

• 索引上的等值查询 (唯一索引，例如主键索引) ，给 不存在的记录 加锁时,优化为间隙锁。

• 表中id为主键索引，我们给不存在的id=5加锁，此时就会在3和8之间加入一个 间隙锁
  

• 查询发现上了间隙锁

• 查看查看意向锁及行锁的加锁情况:

select object schema,object name,index name,lock type,lock mode,lock data from performance schema.data locks;

• 此时我们往（3-8）的间隙里加入数据（id=7），发现进入阻塞状态
  

2.演示：索引上的范围查询(唯一索引)

• 索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止。
• 我们针对既是主键也是唯一索引id，进行范围查询
  
• 查看锁情况
• 查看查看意向锁及行锁的加锁情况:

select object schema,object name,index name,lock type,lock mode,lock data from performance schema.data locks;

• 对19加了一个行锁S，REC_NOT_GAP
• 对25与25之前间隙加了一个临键锁,S
• 对25之后到正无穷supremum pseu加了临键锁,S
  

3.演示：索引上的等值查询(普通索引)——临键锁退化为间隙锁

• 索引上的等值查询(普通索引)，向右遍历时最后一个值不满足查询需求时， 临键锁 退化为间隙锁 (可理解成多出一个间隙锁)
• 前置知识： 我们加的行锁是针对索引加的锁，索引是一个B+树的结构，B+树的节点形成的是一个有序的双向链表
• 现有的记录中有18，因为其不是唯一索引，18之前与之后将来都可能插入字段值为18的记录
  
• 于是乎16和18之间，18和29之间都会上锁；18和29之间是间隙锁，而16和18之间的临键锁，此时会退化为间隙锁；

我们可以看看下面这个例子：

• 我们先对age加上普通索引
  
• 对age=3的记录，加上共享锁
  
• 我们查询锁的情况 注：S是临键锁
• 查看查看意向锁及行锁的加锁情况:

select object schema,object name,index name,lock type,lock mode,lock data from performance schema.data locks;

• 3，3是 临键锁S ，对应的是锁住3和3之前的部分

• 7，7是 临键锁S和 间隙锁GAP ，对应的是所著3和7之间的间隙

• 向右遍历时最后一个值不满足查询需求时， 临键锁 退化为间隙锁 (可理解成多出一个间隙锁)

四.表级锁

表级锁的基本概念＆分类【表锁，元数据锁，意向锁】

• 表级锁，每次操作锁住整张表。锁定粒度大， 发生锁冲突的概率最高 ，并发度最低。应用在MISAM、InnoDB、BDB等存储引擎中。

对于表级锁，主要分为以下三类:

1. 表锁
2. 元数据锁
3. 意向锁

【1】表锁

对于表锁，分为两类:

1. 表共享读锁 (read lock)
2. 表独占写锁 (write lock)

语法：

1. 加锁: locktables 表名..read/write
2. 释放锁: unlock tables/客户端断开连接

演示：

• 加了读锁：其他包括自己客户端只能读不能写

【2】元数据锁：MDL

• 元数据可以直接理解成： 表的结构
• MDL加锁过程是系统 自动控制，无需显式使用 ，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作
• 在MySOL5.5中引入了MDL，当对一张表进行增删改查的时候，加MDL读锁(共享);当对表结构进行变更操作的时候，加MDL写锁(排他)。

不同SQL对应的元数据锁有所不同：

【3】意向锁

1.意向锁的由来

意向锁出现的场景：

• 线程A：有一张表和客户端，我们开启事务，更新id为3的数据，会自动加上 行锁
  

• 此时，我们想给这张表上 表锁————显然，是做不到的，因为和原来的 行锁 冲突了
  

• 线程B：也就是我们想要加表锁前，就要先检查有无行锁；即 逐行检查 ，看下哪一行加了行锁， 这种方式性能很低
  

• 于是乎，为了提高性能，让我们在检查时不用 逐行检查 ——我们加入了 意向锁

意向锁加入以后的情况：

• 线程A：有一张表和客户端，我们开启事务，更新id为3的数据，会自动加上 行锁
• 在此基础上，再给表加上一个 意向锁
• 线程B： 我们想加一个表锁，我们先看有无意向锁，再看所要加的表锁与原来的意向锁是否兼容（读/写锁） ，不兼容则进入阻塞状态，直到线程A提交

2.意向锁的相关语法（意向共享锁＆意向排他锁）（包含语法和演示）

1. 意向共享锁(IS): 与表锁共享锁(read)兼容 ， 与表锁排它锁(write)互斥
2. 意向排他锁(IX): 与表锁共享锁(read)及排它锁(write)都互斥 。意向锁之间不会互斥。

查看查看意向锁及行锁的加锁情况:

select object schema,object name,index name,lock type,lock mode,lock data from performance schema.data locks;

演示：
- 注：TABLE 为表锁 RECORD为行锁

• 如何确定加共享锁是意向锁呢？输入查看代码
• 我们可以看到lock_mode下面表锁对应的是IS，说明加的共享锁是意向共享锁

• 我们知道，意向共享锁(IS): 与表锁共享锁(read)兼容 ， 与表锁排它锁(write)互斥
• 也就意味着此时可以加 表锁（读锁） ，而不能加 表锁（写锁）