1. 概述
MySQL中的锁，按照锁的粒度分，分为以下三类：
- 全局锁：锁定数据库中的所有表。
- 表级锁：每次操作锁住整张表。
- 行级锁：每次操作锁住对应的行数据。
1.1. 前提
读锁 = 共享锁，写锁 = 排他锁
读锁与读锁兼容，读锁与写锁互斥，写锁与写锁互斥
RC 表示Read committed 读已提交事务隔离级别的首字母缩写
RR表示Repeatable Read 可重复读事务隔离级别的首字母缩写
2. 全局锁（库锁）
2.1. 概述
全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，以及更新操作的事务提交语句都将被阻塞。
其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。
2.2. 语法
//加全局锁 flush tables with read lock ; //数据备份 mysqldump [-h ip] -uroot –p1234 itcast > itcast.sql //释放锁 unlock tables ;
3. 表级锁
表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。
对于表级锁，主要分为以下三类：
- 表锁
- 元数据锁
- 意向锁
3.1. 表锁
3.1.1. 语法
对于表锁，分为两类：读锁（read lock），写锁（write lock）
lock tables 表名... read/write; unlock tables / 客户端断开连接 ;
3.1.2. 流程分析
左侧为客户端一，对指定表加了读锁，不会影响右侧客户端二的读，但是会阻塞右侧客户端的写。
左侧为客户端一，对指定表加了写锁，会阻塞右侧客户端的读和写。
3.2. 元数据锁
3.2.1. 概述
meta data lock , 元数据锁，简写MDL。
这里的元数据，大家可以简单理解为就是一张表的表结构。 也就是说，某一张表涉及到未提交的事务时，是不能够修改这张表的表结构的。
MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DML与DDL冲突，保证读写的正确性。
在MySQL5.5中引入了MDL，当对一张表进行增删改查的时候，加MDL读锁(共享)；当对表结构进行变更操作的时候，加MDL写锁(排他)。
3.2.2. 分类
常见的SQL操作，所添加的元数据锁
对应SQL |
锁类型 |
说明 |
lock tables xxx read |
shared_read_only |
|
lock tables xxx write |
shared_no_read_write |
|
select 、select ... lock in share mode |
shared_read |
与SHARED_READ、SHARED_WRITE兼容，与EXCLUSIVE互斥 |
insert 、update、delete、select ... for update |
shared_write |
与SHARED_READ、SHARED_WRITE兼容，与EXCLUSIVE互斥 |
alter table ... |
exclusive |
与其他的MDL都互斥 |
3.3. 意向锁
为了避免DML在执行时，加的行锁与表锁的冲突，在InnoDB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查。
- 意向共享锁(IS): 由语句select ... lock in share mode添加 。 与 表锁共享锁(read)兼容，与表锁排他锁(write)互斥。（查询手动增加）
- 意向排他锁(IX): 由insert、update、delete、select...for update添加 。与表锁共享锁(read)及排他锁(write)都互斥，意向锁之间不会互斥。（增删改自动增加）
一旦事务提交了，意向共享锁、意向排他锁，都会自动释放。
3.3.1. 流程分析
场景A（没有意向锁）
- 首先客户端一，开启一个事务，然后执行DML操作，在执行DML语句时，会对涉及到的行加行锁。
- 当客户端二，想对这张表加表锁时，会检查当前表是否有对应的行锁，如果没有，则添加表锁，此时就会从第一行数据，检查到最后一行数据，效率较低。
场景B（有意向锁）
- 首先客户端一，在执行DML操作时，会对涉及的行加行锁，同时也会对该表加上意向锁。
- 当客户端二，在对这张表加表锁的时候，会根据该表上所加的意向锁来判定是否可以成功加表锁，而不用逐行判断行锁情况了。
- 如果判断当前表中有意向锁，那么此时线程B则执行的加锁处于阻塞状态，直到线程A中的行锁释放和意向锁释放之后，线程B则可以正常执行。
3.3.2. 语法
//意向共享锁 select ... lock in share mode //意向排他锁 select ... for update
4. 行级锁
行级锁，每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。应用在InnoDB存储引擎中。
- 行锁（Record Lock）
- 间隙锁（Gap Lock）
- 临键锁（Next-Key Lock）
4.1. 行锁（记录锁）
4.1.1. 概述
- 行锁（Record Lock）：锁定单个行记录的锁，防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。
InnoDB实现了以下两种类型的行锁：
- 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁。
- 排他锁（X）：允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。
4.1.2. 分类
SQL |
行锁类型 |
说明 |
INSERT ... |
排他锁 |
自动加锁 |
UPDATE ... |
排他锁 |
自动加锁 |
DELETE ... |
排他锁 |
自动加锁 |
SELECT（正常） |
不加任何锁 |
|
SELECT ... LOCK IN SHARE MODE |
共享锁 |
需要手动在SELECT之后加LOCK IN SHARE MODE |
SELECT ... FOR UPDATE |
排他锁 |
需要手动在SELECT之后加FOR UPDATE |
4.1.3. 特点
默认情况下，InnoDB在 RR事务隔离级别运行，InnoDB使用 next-key 锁进行搜索和索引扫描，以防止幻读。
- 针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁。
- InnoDB的行锁是针对于索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，此时 就会升级为表锁。
演示
无索引行锁升级为表锁
在客户端一中，开启事务，并执行update语句，更新name为Lily的数据，也就是id为19的记录 。 然后在客户端二中更新id为3的记录，却不能直接执行，会处于阻塞状态，为什么呢？
原因就是因为此时，客户端一，根据name字段进行更新时，name字段是没有索引的，如果没有索引，此时行锁会升级为表锁(因为行锁是对索引项加的锁，而name没有索引)。
再针对name字段建立索引
客户端一，开启事务，然后依然是根据name进行更新。而客户端二，在更新id为3的数据时，更新成功，并未进入阻塞状态。 这样就说明，我们根据索引字段进行更新操作，就可以避免行锁升级为表锁的情况。
4.2. 间隙锁
- 间隙锁（Gap Lock）：锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。
间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存，一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用间隙锁。
4.3. 临键锁
- 临键锁（Next-Key Lock）：行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap。在RR隔离级别下支持。
4.3.1. 特点
默认情况下，InnoDB在RR事务隔离级别运行，InnoDB使用临键锁进行搜索和索引扫描，以防止幻读。如果把事务的隔离级别降级为RC，临键锁则也会失效。
普通列：临键锁中的间隙锁和记录锁均为表级别；
普通索引列：
- 非临界值：间隙锁为被查询的记录所在的区间，记录锁不生效
- 临界值：间隙锁为被查询记录所在的相邻两个区间，记录数退化为行锁
- 范围值：间隙锁和记录数均为查询条件所涉及到的区间
唯一索引或主键索引列：
- 非临界值：间隙锁为被查询的记录所在的区间，记录锁不生效
- 临界值：间隙锁失效，记录锁退化为行锁
- 范围值：间隙锁和记录数均为查询条件所涉及到的区间
演示
- 记录不存在即临键锁失去行锁，变化为间隙锁
- 我们知道InnoDB的B+树索引，叶子节点是有序的双向链表。 假如，我们要根据这个二级索引查询值为18的数据，并加上共享锁，我们是只锁定18这一行就可以了吗？ 并不是，因为是非唯一索引，这个结构中可能有多个18的存在，所以，在加锁时会继续往后找，找到一个不满足条件的值（当前案例中也就是29）。此时会对18加临键锁，并对29之前的间隙加锁。
select * from table where id = 18 lock in share model；
select * from table where id ≤ 18 lock in share model；
