MySQL Innodb 中的排它锁、共享锁、意向锁、记录锁、间隙锁、临键锁、死锁讲解

一、MySQL 锁机制

MySQL作为流行的关系型数据库管理系统之一，在处理并发访问时，锁起着至关重要的作用。锁的使用可以确保数据的完整性，同时也是实现并发操作的必备工具。在MySQL Innodb 引擎中锁可以理解为两个方向的东西，一个是基本锁的类型 ，一个是锁粒度的策略。

对于锁的类型 主要为我们常见的排他锁 和共享锁，排他锁又称独占锁，允许事务修改数据并阻止其他事务同时获取相同资源任何类型的锁。用于保护数据的完整性和一致性，确保在修改数据时不会发生冲突。共享锁允许多个事务同时读取同一行的数据，但不允许任何事务修改数据。

对锁粒度的策略 则是建立在排他锁和共享锁之上的方案。主要控制锁的粒度大小，实际锁的方式还是共享锁或排他锁。例如记录锁、间隙锁、临键锁等，不同的策略锁的粒度范围不同，如记录锁会锁住一行数据，间隙锁会锁住一个范围的数据等，本文将深入探讨MySQL Innodb 引擎中的锁机制。

二、基本锁的类型

2.1 排它锁

排他锁又称为写锁，简称X锁，是一种悲观锁，具有悲观锁的特征，如一个事务获取了一个数据行的X锁，其他事务尝试获取锁时就会等待另一个事务的释放。其中在 InnoDB 引擎下做写操作时 （UPDATE、DELETE、INSERT）都会自动给涉及到的数据加上 X 锁，因此当多线程情况下对同一条数据进行更新，在MySQL中不会出现线程安全问题。

其中 SELECT 语句默认不会加锁，如果查询的数据已经存在 X 锁，则会返回其最近提交的数据，如果希望每次获取的数据都是更新后最新的数据，当存在有更新时，则等待更新完成后获取新的值，这种情况下就需要对 SELECT 语句也要存在 X 锁，其中 SELECT 语句加 X 锁的话需要使用 FOR UPDATE 语句。

比如：当前有一张表结构如下：

CREATE TABLE `lock` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

写入一条测试数据：

INSERT INTO `testdb`.`lock`(`id`, `name`) VALUES (1, 'lock1');

下面，我使用 Navicat 开启了两个对话框，我在第一个对话框中，使用手动提交事务的方式执行更新语句，并且既不提交也不回滚事务：

BEGIN;
UPDATE `lock` SET `name` = 'lock2' WHERE id = 1; 

下面在另一个对话框中，查询 id = 1 的数据：

SELECT * FROM `lock` where id = 1

可以看到，并没有拿到最新的内容，因为此时 X 锁还没有释放，那此时对查询语句进行调整下，加上 FOR UPDATE 语句：

SELECT * FROM `lock` where id = 1 FOR UPDATE

此时会发现，查询语句一直在等待，因为这个查询语句在等待 X 锁的释放，下面对第一个对话框中，执行提交事务：

COMMIT;

在回到第二个对话框中查看：

已经拿到最新的值。这里需要注意下，你的是不是出现了超时报错，这是因为 Innodb 引擎对等待锁有个等待超时时间，默认情况下是 50s ，可以通过下面指令查看：

SHOW VARIABLES LIKE "Innodb_lock_wait_timeout"

如果感觉太小，可以通过下面指令调整：

SET innodb_lock_wait_timeout = 100

上面的操作已经感觉出来 X 锁的效果，那当两个 SELECT 语句都加上 FOR UPDATE 呢，比如在第一个回话框中，使用手动事务执行 SELECT 语句，同样不提交事务:

BEGIN;
SELECT * FROM `lock` where id = 1 FOR UPDATE;

在第二个对话框同样执行相同的代码，可以发现被阻塞掉了。

当第一个提交事务后，第二个紧接着也查出了信息，这也正符合排他锁的特征。

2.2 共享锁

共享锁可以理解为读锁，简称S锁，可以对多个事务SELECT情况下读取同一数据时不会阻塞，但是如果存在写操作时 （UPDATE、DELETE、INSERT），SELECT语句也会被阻塞，在MySQL中使用 S 锁需要使用 LOCK IN SHARE MODE。

例如还是开启两个对话框，在第两个对话框中，都查询 id = 1 的数据，并加上 S 锁，最后同样不提交事务：

BEGIN;
SELECT * FROM `lock` where id = 1 LOCK IN SHARE MODE;

可以发现两个都拿到了数据，对两个都提交事务后，假如第一个对话框中是更新操作，最后同样不提交事务：

BEGIN;
UPDATE `lock` SET `name` = 'lock3' WHERE id = 1 ;

在第二个对话框中还是加上 S 锁的查询操作：

BEGIN;
SELECT * FROM `lock` where id = 1 LOCK IN SHARE MODE;

可以看到查询被阻塞了，当第一个对话框中提交了事务，这里才会返回结果：

2.3 意向锁

MySQL中的意向锁是一种特殊类型的锁，用于在表级别上表示事务可能要对表中的某些行进行修改。这种锁可以协调多个事务并发访问同一表，以确保数据的完整性和一致性。

意向锁分为两种类型：意向共享锁（IS）和意向排他锁（IX）。它们是在行级锁之上的一种辅助锁，用于表级锁的管理，意向锁是一种不与行级锁冲突的表级锁。

• 意向共享锁（IS）：表示事务打算在表中的某些行上设置共享锁（即读锁），但不是在整个表上设置排他锁（即写锁）。其他事务可以同时获取意向共享锁和共享锁，但不能获取排他锁。

• 意向排他锁（IX）：表示事务打算在表中的某些行上设置排他锁（即写锁），但不是在整个表上设置共享锁。其他事务可以同时获取意向排他锁和共享锁，但不能获取排他锁。

意向锁的引入主要是为了协调事务对表级锁的请求。当一个事务要在某一行上设置锁时，它会首先尝试获取意向锁。如果其他事务已经在表上设置了排他锁，则意向锁会阻止其他事务再获取共享锁，从而避免了读取到不一致的数据。同样，如果其他事务已经在表上设置了共享锁，则意向锁会阻止其他事务再获取排他锁，从而避免了并发写操作导致的数据破坏。

意向锁之间是互相兼容的

	IX	IS
IX	兼容	兼容
IS	兼容	兼容

意向锁和排他锁、共享锁之间只有共享级别的锁兼容：

	X	S
IX	冲突	冲突
IS	冲突	兼容

例如：在事务1中写入一条数据：

BEGIN;
INSERT INTO `lock`(id,name) VALUES(11,"lock1");

然后查询锁的情况：

SELECT * FROM	`performance_schema`.data_locks  WHERE OBJECT_NAME = 'lock'

可以看到加了表级意向排他锁。

然后在事务2中准备锁表：

LOCK TABLE `lock` WRITE;

可以看出被阻塞了。

三、锁粒度的策略

3.1 记录锁

记录锁（Row Lock）也叫行锁，将锁的粒度控制在最小的一行数据上，是一种用于控制并发访问的锁定机制，它允许多个事务同时操作同一张表中的不同行，而不会相互干扰，从而提高并发能力。记录锁包含了共享锁和排它锁，锁定的资源是索引记录，如果表中的字段没有索引，InnoDB 会创建一个隐藏的聚集索引并使用该索引进行记录锁定。

例如：在事务1中，查询所有数据：

BEGIN;
SELECT * FROM `lock` FOR UPDATE;

然后查看锁的情况：

SELECT * FROM	`performance_schema`.data_locks  WHERE OBJECT_NAME = 'lock'

从 LOCK_DATA 可以看出锁的资源是主键ID。

3.2 间隙锁

间隙锁（Gap Lock）是 MySQL 中一种特殊类型的锁，用于在事务中防止其他事务插入新记录或修改范围内的数据，保证数据的一致性和防止幻读。间隙锁通常与范围条件查询结合使用，确保数据的完整性和一致性。

例如：当事务 1 查询 id > 0 and id < 5 的数据时，如果此时事务 2 对该范围的数据写入了一条数据，而这个数据如果在事务1中继续操作，就有可能出现幻读。

所以为了避免这个问题，InnoDB 引擎中引入了间隙锁机制，即在索引中的两个值之间锁定一个间隙，阻止其他任何事务在该间隙上进行插入或修改操作，从而保证数据的一致性和防止幻读。

注意：间隙锁只在 Innodb 引擎可重复读隔离级别中存在。

例如，查询一个范围：

BEGIN;
SELECT * FROM `lock` where id > 1 and id < 5 FOR UPDATE

然后查看锁情况：

SELECT * FROM	`performance_schema`.data_locks  WHERE OBJECT_NAME = 'lock'

可以看到锁住了2-5这个范围的数据，细心的可以发现 5 其实没有在查询条件中，但是也被锁住了，这就和间隙锁的范围有关了，间隙锁会锁住索引之间的数据或者第一个索引前面或者最后一个索引后面。这里 5 就是最后一个索引后面的数据。

注意，如果根据 id > 13，此时id最大值是11的情况下，则会锁住 11 - 正无穷 的范围：

BEGIN;
SELECT * FROM `lock` where id > 13 FOR UPDATE

查看锁情况：

SELECT * FROM	`performance_schema`.data_locks  WHERE OBJECT_NAME = 'lock'

看到LOCK_DATA为 supremum pseudo-record，它是 InnoDB 中定义的一种特殊记录，我们可以理解为 +∞。

如果此时写入一个id=15的数据，就会被阻塞：

BEGIN;
insert into `lock`(id,name) values(15,'lock');

3.3 临键锁

临键锁是索引记录上的记录锁（Record Locks）和索引记录之前的间隙上的间隙锁（Gap Locks）的组合。也就是临键锁不仅会用记录锁锁住相关的行数据，也会用间隙锁锁住一个范围的数据。同样临键锁的目标也是保证数据的一致性和防止幻读。临键锁针对间隙范围时遵循左开右闭的原则。

具体触发策略为：

• 当筛选字段是唯一索引时，进行等值查询时，针对目标数据增加记录锁。没有匹配到任何记录的时候，增加间隙锁。

• 当筛选字段是普通索引时，进行等值查询时，针对目标数据增加记录锁，然后向右遍历直到最后一个值不满足查询条件时，这个范围增加间隙锁。

例如：给 name 字段添加普通索引：

ALTER TABLE `lock` ADD INDEX index_name(name);

然后进行普通索引等值查询：

BEGIN;
SELECT * FROM `lock` where name = 'lock1' FOR UPDATE

查看锁情况：

SELECT * FROM	`performance_schema`.data_locks  WHERE OBJECT_NAME = 'lock'

可以看到锁住了 lock1 的普通索引和主键索引，同时也将 lock1之后的普通索引 lock10给锁上了，锁的类型为间隙锁 。

然后当使用唯一索引时，查询目标不存在情况下。

例如数据库中没有 id=10 的记录，但我们还要查询 id=10 的数据：

BEGIN;
SELECT * FROM `lock` where id = 10 FOR UPDATE

然后查看锁情况：

SELECT * FROM	`performance_schema`.data_locks  WHERE OBJECT_NAME = 'lock'

可以看到主键为 11 的数据被锁住了，锁的类型是间隙锁。

四、死锁

上面了解到了MySQL中的各种锁机制，既然存在锁肯定会有死锁的风险。例如事务1中更新了 id=1 的数据，事务 2 中更新了 id = 2 的数据，此时事务1 准备更新 id=2 的数据，而事务 2 准备更新 id=1 的数据，需要互相等待对方释放锁，此时就是死锁。

好在 MySQL 中默认开启了死锁检测，当发现某个事物的操作可能会造成死锁时，会主动回滚当前事务。

可以通过下面指令查看是否开启：

SHOW GLOBAL VARIABLES LIKE 'innodb_deadlock_detect';

例如：在事务1中查询 id=1 的数据，并添加排他锁：

BEGIN;
SELECT * FROM `lock` where id = 1 FOR UPDATE;

此时事务2，查询 id=2 的数据，并添加排他锁：

BEGIN;
SELECT * FROM `lock` where id = 2 FOR UPDATE;

然后事务1中，又查询 id=2 的数据，添加排他锁：

SELECT * FROM `lock` where id = 2 FOR UPDATE;

由于id=2的锁被事务2持有，此时会阻塞等待：

紧接着又在事务2中，查询 id=1 的数据，添加排他锁：

SELECT * FROM `lock` where id = 1 FOR UPDATE;

此时可以发现事物2异常回滚了，给出了提示是发现了死锁：