概述

锁是计算机协调多个进程或者线程并发访问某一资源的机制，在数据库中，除传统的计算资源（CPU、RAM、I/O）的争用外，数据也是一种提供给许多用户共享的资源，如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来讲，所对数据而言显得尤其重要，也更加复杂。

锁的分类

在MySQL中，按照所得粒度进行分类：

• 全局锁：锁定数据库中所有的表
• 表级锁：每次操作锁住整张表
• 行级锁：每次操作锁住对应的行

全局锁

对整个数据库实例进行加锁，加锁后整个实例就处于只读状态，后续的DML（数据库操作语句）的写语句、DDL语句（数据库控制语句），已经更新操作的事务提交语句都将被阻塞。

其典型的使用场景就是做库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SMUGjTeI-1677505611375)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227162636631.png)]

基本语法：

加锁

flush tables with read lock

解锁：

unlock tables;

特点

数据库中加全局锁，是一个比较重的操作，存在以下几个问题：

1. 如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆
2. 如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志，会导致主从延迟

在InnoDB引擎中，我们可以在备份时加上参数 –single-transaction 参数来完成不加锁的一致性数据备份。这种方式实际上是通过快照读来实现的

表级锁

介绍

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

分类

1. 表锁
2. 元数据锁（meta data local， MDL）
3. 意向锁

表锁

对于表锁，分为两类

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

语法：

加锁： lock tables 表名… read/write

解锁：unlock tables / 客户端断开连接

读锁

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ppcga3rL-1677505611376)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227164027246.png)]

会阻塞其他线程的写，但是不会阻塞其他线程的读

测试

加一个读锁

流程：

我们向一个表中加入锁，加入锁之后对两个客户端进行读操作：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-64ZxIUcU-1677505611376)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227165421776.png)]

可以看到读操作没有任何影响，那么就进行更新操作，现在左边进行更新操作:

做窗口直接报错：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rAfpszIN-1677505611377)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227165612934.png)]

在右窗口进行一个测试：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nQ2ozG1b-1677505611377)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227165728241.png)]

此时光标一直在闪烁，说明这里已经被阻塞了，那么我们关闭锁，在进行尝试

-- 关闭锁
unlock tables;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n1A9pg5p-1677505611378)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227165918174.png)]

输完之后后面直接弹出，右边报错是因为我字段名字打错了

写锁测试

加入了写锁之后，加锁的客户端既可以读也可以写，而其他的客户端所有的读写操作都会被拒绝

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iy6sESDo-1677505611378)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227170222458.png)]

写锁测试

在左边的客户端加一个写锁。

lock tables user write;

	读操作	写操作
左客户端		[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r9DUV7oM-1677505611379)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227170659443.png)]
右客户端	[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qsnBICyD-1677505611380)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227170458112.png)]	[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6TeYiHOi-1677505611380)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227170654218.png)]

可见加入了写锁之后，其他客户端的所有读写操作都被阻塞了，都在等待锁的释放

释放锁之后：

unlock tables;

锁释放之后，右客户端阻塞结束，直接进行了写入操作，我们顺带进行一个查询操作

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SbobwFeV-1677505611381)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227170951274.png)]

可见这时候任何操作都没有影响

元数据锁

元数据锁（meta data local，MDL），MDL加锁过程是系统自动控制的，无需显式的使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护元数据的数据一致性。在表上有事务活动时候，不可以对元数据进行写入操作。

作用：为了避免DML与DDL冲突，保证读写的正确性

在MySQL5.5中引入了MDL，当对一张表进行增删改查的时候，加MDL读锁（共享）；当对表结构进行变更操作的时候，加MDL锁（排他锁）

对应的SQL	锁类型	说明
lock tables xxx read/write	SHARED_READ_ONLY/SHARED_NO_READ_WRITE
select、select …. lock in share mode	shared_read	与shared_read、shared_write兼容，与exclusive (独占)互斥
insert、update、delete select … for update	shared_read	与shared_read、shared_write兼容，与exclusive (独占)互斥
alter table…	exclusive	与其他的MDL都互斥

意向锁

为了避免DML在执行时，加的行锁与表锁的冲突，在Inn哦DB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查。

大致流程？

比如说增删改的过程会自动再给数据库加上一个行锁，加上行锁后如果有其他的操作需要加锁（比如说表锁、行锁），如果没有意向锁，那么就会一行一行的遍历去查看是否有锁，这样子的效率比较低，意向锁就是在增删改加行锁的时候额外加一个，然后当其他所操作来的时候看到意向锁直接进行一个阻塞而不是一行一行遍历。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UV9UAqCI-1677505611381)(https://kele-1305880580.cos.ap-beijing.myqcloud.com//blog/image-20230227174129614.png)]

分类

1. 意向共享锁(IS):由语句select… lock in share mode 添加。
   1. 与表锁共享锁(read)兼容，与表锁(write)互斥
2. 意向排他锁(IX):由update、insert、delete、select… for update添加。
   1. 与表锁(read)及排他锁(write)都互斥，意向锁之间不会互斥

行级锁

介绍

行级锁，每次操作锁住对应行的数据。锁的粒度最小，发生冲突的概率最低，并发度最高，应用在InnoDB存储引擎中

InnoDB的数据是基于索引组织的，行所示通过对索引上的索引项加锁实现的，而不是对记录加的锁，对于行级锁，主要分为三类：

1. 行锁（有的地方也称之为记录所）:缩影单个行记录的锁，防止其他事务对此进行update和delete。在RC、RR隔离级别下都支持
2. 间隙锁：锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事务在这个间隙进行insert产生幻读，在RR级别下都支持
3. 临键锁：行锁和间隙锁，同时锁住数据，并记录数据前面的间隙Gap，在RR隔离级别都支持

行锁

InnoDB实现了一下两种类型的行锁：

1. 共享锁(S):允许一个事务去读一行，组织其他食物获得相同的数据集的排他锁
2. 排他锁(X):允许获取排他锁的事务更新数据，组织其他食物获得相同数据集的共享锁和排他锁

SQL	行所类型	说明
INSERT…	排他锁	自动加锁
UPDATE…	排他锁	自动加锁
DELETE	排他锁	自动加锁
SELECT（正常）	不加任何速锁
SELECT … LOCK IN SHARE MODE	共享锁	需要手动在select 之后加上lock in share mode
SELECT … FOR UPDATE	排他锁	需要手动在SELECT之后加for UPDATE

在默认情况下，Inn哦DB在REPEATABLE READ（可重复读）隔离级别运行，InnoDB使用next-key【临键锁】进行搜索和索引扫描，以防止幻读：

1. 针对唯一索引进行检索，对已经存在的记录进行等值匹配时，将会自动优化为行锁
2. InnoDB的行锁是针对于加索引的锁，不通过索引条件检索的数据，那么InnoDB将对表中的所有记录进行加锁，此时就会升级为表锁。

间隙锁/临键锁

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

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

注意：间隙锁唯一目的是为了防止其他事务插入间隙，间隙锁可以共存，一个事物采用的间隙锁不会阻止另一个事务在同一个间隙上采用间隙锁