MySQL锁（读锁、共享锁、写锁、S锁、排它锁、独占锁、X锁、表锁、意向锁、自增锁、MDL锁、RL锁、GL锁、NKL锁、插入意向锁、间隙锁、页锁、悲观锁、乐观锁

小松聊PHP进阶2024-03-10 14:56

本文说明的是MySQL锁，和操作系统或者编程语言的锁无关。

概念

作用：在并发情况下让数据正确的读写。 优点：并发情况下对数据读写可控，防止出错。 缺点：降低性能、增加难度。

分类

  • 数据操作类型划分
    • 读锁（共享锁、S锁）
    • 写锁（排它锁、独占锁、X锁）
  • 粒度划分
    • 表级锁
      • S锁、X锁
      • 意向锁
      • 自增锁
      • 元数据锁
    • 行级锁
      • 记录锁
      • 间隙锁
      • 临键锁
      • 插入意向锁
    • 页级锁
  • 严格度划分
    • 悲观锁
    • 乐观锁
  • 加锁方式
    • 隐式锁
    • 显示锁
  • 其它
    • 全局锁
    • 死锁

测试用表

sql 复制代码 
CREATE TABLE `cs` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `num1` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '数字列1',
  `num2` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '数字列2',
  `s1` varchar(2000) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '字符串列1',
  `s2` varchar(2000) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '字符串列2',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

INSERT INTO `temp`.`cs` (`id`, `num1`, `num2`, `s1`, `s2`) VALUES (1, 1, 1, 'abc', 'xyz');
INSERT INTO `temp`.`cs` (`id`, `num1`, `num2`, `s1`, `s2`) VALUES (2, 2, 2, 'ABC', 'XYZ');

读锁、共享锁、S锁

读锁、共享锁、S锁（Share Lock）是一个东西。 锁的是：允许同时有多个事务，对数据只能读，不能写。 写法：

sql 复制代码 
select ... lock in share mode;
select ... for share; #MySQL8

测试：

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 select * from cs where id = 1 lock in share mode; select * from cs where id = 1 lock in share mode; 双方添加共享锁，都能成功添加
3 commit; commit; 正常提交事务，无报错

写锁、排它锁、X锁、独占锁

写锁、排它锁、X锁（Exclusive Lock）、独占锁是同一个东西。 锁的是：仅允许同时有1个锁独占该事务，具有排它性，不允许其它任何类型的锁再占用该事务。

sql 复制代码 
select ... for update;

测试： X锁排斥S锁1

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 select * from cs where id = 1 lock in share mode; select * from cs where id = 1 for update; 会话A添加S锁，会话B添加X锁
3 / 阻塞 会话B添加X锁被阻塞，说明X锁有排它性
4 commit; / 会话B X锁添加成功
5 / commit; 会话B提交事务，结束流程

X锁排斥S锁2

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 select * from cs where id = 1 for update; select * from cs where id = 1 lock in share mode; 会话A添加X锁，会话B添加S锁
3 / 阻塞 会话B添加S锁被阻塞，说明X锁有排它性
4 commit; / 会话B S锁添加成功
5 / commit; 会话B提交事务，结束流程

X锁排斥X锁

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 select * from cs where id = 1 for update; select * from cs where id = 1 for update; 双方添加X锁
3 / 阻塞 会话B添加X锁阻塞，证明排它性
4 commit; / 会话B X锁添加成功
5 / commit; 会话B提交事务，结束流程

S锁、X锁常见误区

注意：在同一个事务里面，行级X锁或S锁，允许其它SQL语句对此行的写操作。 如下，每条SQL都能成功执行。 所以说锁，锁的是对外的事务，对内（当前会话）不做限制。

sql 复制代码 
start transaction;
select * from cs where id = 1 for update;
update cs set num1 = 2 where id = 1;
commit;

start transaction;
select * from cs where id = 1 lock in share mode;
update cs set num1 = 2 where id = 1;
commit;

注意：在任意个事务里面，可以对同一条不存在的数据共同添加X和S锁，不会阻塞。

sql 复制代码 
事务A
start transaction;
select * from cs where id = 1234 for update;
select * from cs where id = 1234 lock in share mode;

事务B
start transaction;
select * from cs where id = 1234 for update;
select * from cs where id = 1234 lock in share mode;

事务A
commit;

事务B
commit;

注意：事务A加了X锁，不影响事务B读这条数据。

sql 复制代码 
事务A
start transaction;
select * from cs where id = 1 for update; #能正常读出数据

事务B
start transaction;
select * from cs where id = 1;

事务A
commit;

事务B
commit;

对阻塞超时时间的优化

遇到X锁会阻塞，默认阻塞50秒，50秒过后阻塞停止，但不会自动的回滚或者提交事务。MySQL提供了一些阻塞时间的优化方向 方式1：配置优化

sql 复制代码 
查看阻塞时间，单位秒
show variables like 'innodb_lock_wait_timeout';
或
select @@innodb_lock_wait_timeout;

修改
set session innodb_lock_wait_timeout = 10; #当前会话生效
或
set global innodb_lock_wait_timeout = 10; #全局生效，重启后新配置丢失
注意global的修改对当前线程是不生效的，只有建立新的连接才生效

或者修改配置文件
vim /etc/my.cnf
[mysqld]
innodb_lock_wait_timeout = 10

方式2：SQL语句层面，MySQL8新特性 select ... nowait：会立即停止，但报错。 select ...skip locked：会立即停止，但不会报错，结果中不包含被锁定的行。

表锁、页锁、行锁

这是锁定的粒度，3个依次递减，粒度越小越好。力度小意味着更少的资源被锁定，可以提高并发性。

表锁

表锁就是锁住了整张表，所以表锁比行锁，更不容易发生死锁的情况。 注意：MyISAM引擎使用select，会给当前表加上S锁，在写操作时会加上X锁。

sql 复制代码 
查看一些数据库的表，都加了那些锁
show open tables;
In_use: 是否正在被使用，如果为 1 则表示该表正在被某个线程使用。
Name_locked: 是否被上了表级锁，如果为 1 则表示该表被锁定。
+--------------------+------------------------------------------------------+--------+-------------+
| Database           | Table                                                | In_use | Name_locked |
+--------------------+------------------------------------------------------+--------+-------------+
| performance_schema | events_waits_summary_by_user_by_event_name           |      0 |           0 |
| performance_schema | events_waits_summary_global_by_event_name            |      0 |           0 |
+--------------------+------------------------------------------------------+--------+-------------+


为某个表添加X锁
lock table 表名 write;

为某个表添加S锁
lock table 表名 read;

取消表锁，部分XS
unlock tables;

表锁权限如下（MySQL5.7）

表锁类型 当前会话对当前表可读 当前会话对当前表可写 其它会话对当前表可读 其它会话对当前表可写
S锁 是 否 是 阻塞
X锁 阻塞 是 阻塞 阻塞

表级锁->意向锁、意向共享锁、意向排它锁、IS锁、IX锁

意向锁（Intention Shared Lock）是自动维护的锁，用于表级别上表明事务对表中某个行的操作意向，意思是在表级别上声明了某个行已经加锁，优化事务之间的并发访问。意向锁分为两种：意向共享锁（IS）和意向排它锁（IX）。 MyISAM引擎不支持，InnoDB引擎支持。 MySQL添加行级锁，都会向上声明添加了意向锁。 注意意向排它锁与意向排它锁不冲突，意向排它锁与意向共享锁都不冲突，如果冲突了，锁的灵活性将大大降低。距离说明：两个不同的行X锁各生成一个IX锁，如果IX锁冲突，则无法创建两个行X锁，这种巨大的bug不允许出现。

优点：

  • 提高并发性：如果没有意向锁，在一个百万级的大表中加一个锁，可能需要逐行遍历，看看有没有加其它锁，会影响当前添加的锁，但是有了意向锁，在表的层面就可以获取先前的锁，提高性能。
  • 避免死锁：通过意向锁，可以快速判断哪些锁请求是互斥的，减少锁任务堆积引起的复杂度增加，复杂度一上来，就容易有死锁。

演示：行X锁与表S锁

步骤 会话A 会话B 说明
1 start transaction; / 会话A开启事务
2 select * from cs where id = 1 for update; / 会话A加一个行X锁，相当于自动添加了一个IX锁
3 / lock table cs read; 会话B添加表S锁
4 / 阻塞 这个过程就是表锁检测到了事先添加的IX锁，行级X锁排斥表级S锁，阻塞了
5 commit; 成功加上了表级S锁 会话A事务提交，锁资源释放
6 / unlock tables; 释放表级S锁

表级锁->自增锁、AI锁

自增锁（Auto Increment Lock）是指对自增长列（一般是主键）确保唯一性的一种锁机，如果没有自增锁，多个事务并发的执行，该列的值就可能一致。 为了避免重复，自增锁可能会导致插入操作的串行化，降低并发性能，这是它的缺点。 演示：

步骤 会话A 会话B 说明
1 start transaction; start transaction; 双方开启事务
2 INSERT INTO cs (num1, num2, s1, s2) VALUES (2, 2, 'ABC', 'XYZ'); INSERT INTO cs (num1, num2, s1, s2) VALUES (2, 2, 'ABC', 'XYZ'),(2, 2, 'ABC', 'XYZ'); 双方新增3条记录
3 commit commit; 提交事务
4 select id from cs select id from cs 并未发现报错，或者id重复的现象

表级锁->元数据锁、MDL锁

MDL（Metadata Lock）听起来高大上，实际上就是DDL操作时自动加锁，所以不需要手动处理。 当要对表做增删改查操作时，会获取一个 MDL 读锁来阻止对表结构的修改。 更改表结构时，会加MDL写锁，阻塞其它线程的读写操作，直到结构变更操作完成。 演示 MDL读锁：

步骤 会话A 会话B 说明
1 start transaction; / 会话A开启事务
2 INSERT INTO cs (num1, num2, s1, s2) VALUES (2, 2, 'ABC', 'XYZ'); alter table cs add index (num1); 会话B新增一个普通索引
3 / 阻塞 会话B被阻塞
4 commit; 索引添加成功 MDL锁释放

演示 MDL写锁：

步骤 会话A 会话B 会话C 说明
1 start transaction; start transaction; / AB方开启事务
2 INSERT INTO cs (num1, num2, s1, s2) VALUES (2, 2, 'ABC', 'XYZ'); alter table cs add index (num2); / 会话B新增一个普通索引
3 / 阻塞 / 用会话A的MDL读锁去阻塞会话B
4 / / select * from cs 用会话B的MDL写锁去阻塞会话C
5 / 阻塞 阻塞 MDL写锁阻塞了查询操作
6 rollback; rollback; 成功查询出数据 事务回滚，锁资源释放。但undo log不记录DDL语句，所以索引被添加无法回滚。

行锁->记录锁、RL锁

记录锁（Record Lock）就是普通的对某一行上的X或者S锁。 注意InnoDB引擎下，支持行锁MyISAM不支持。 测试：

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 select * from cs where id = 1 lock in share mode; select * from cs where id = 1 lock in share mode; 双方添加共享锁，都能成功添加
3 commit; commit; 正常提交事务，无报错

行锁->间隙锁、GL锁

间隙锁（Gap Lock）就是在数据间隙加的锁，用于防止事务在一个范围内插入新的符合条件的行，以避免中间插入的幻读的问题（MySQL默认的RR隔离级别会产生幻读问题）。 例如一个一个不连续的id列，1,6,10，如果在1~6之间添加一个锁，就可以1~6防止幻读的插入操作，10后面间隙锁防止幻读就失效了，需要再次声明新的间隙锁。1~6之间没有具体的数据，所以X间隙锁，或者是S间隙锁，没有什么区别。

MySQL默认的RR级别会产生幻读，幻读是指在同一事务中，先后执行相同的查询范围，查询到的数量不一致（mysql的select机制测不出来，两个事务需要插入相同的id引起的报错才能测出来），在并发环境中，幻读通常是因为其他事务在同一范围内插入新数据导致的。以下的演示，不演示幻读，只演示间隙锁阻止幻读。

测试：

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 select * from cs where id = 4 lock in share mode; INSERT INTO cs (id, num1, num2, s1, s2) VALUES (3, 1, 1, 'abc', 'xyz'); 会话A添加间隙锁，会话B插入数据这个区间的数据
3 / 阻塞 可见间隙锁可以阻止区间幻读
4 commit; commit; 会话A关闭事务，会话B提交插入数据

当前id最大值为10，测试大于10的幻读区间

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 sselect * from cs where id = 14 lock in share mode; INSERT INTO cs (id, num1, num2, s1, s2) VALUES (10000, 1, 1, 'abc', 'xyz'); 会话A添加间隙锁，会话B插入id为10000的数据
3 / 阻塞 可见间隙锁可以防止最大记录 ~ +∞之间的幻读
4 commit; commit; 会话A关闭事务，会话B提交插入数据

当前id最大值为100，同样的方法测试小于100的幻读区间

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 sselect * from cs where id = 10001 lock in share mode; INSERT INTO cs (id, num1, num2, s1, s2) VALUES (9999, 1, 1, 'abc', 'xyz'); 会话A添加间隙锁，会话B插入id为9999的数据
3 / 成功插入 间隙锁未能阻塞幻读插入
4 commit; commit; 会话A关闭事务，会话B提交插入数据

行锁->临键锁、NKL锁

临键锁（next-key lock）相当于记录锁+间隙锁，用于防止幻读的锁。 测试：现表中有id为1,6,10三条数据。

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 select * from cs where id between 1 and 6 lock in share mode; INSERT INTO cs (id, num1, num2, s1, s2) VALUES (4, 1, 1, 'abc', 'xyz'); 会话A添加临键锁，会话B插入id为4的数据
3 / 阻塞 临键锁阻塞幻读插入
4 commit; commit; 双方提交事务，结束流程

行锁->插入意向锁、IIL锁

插入意向锁（Insert Intention Lock）是间隙锁的一种，由insert行插入前的操作。该锁表示插入的意图，即插入同一索引间隙的多个事务如果没有在间隙内的相同位置插入，则insert不需要相互等待。 通俗讲就是如果间隙锁得到了释放，则需要insert的多个事务，不会阻塞。 测试：现表中有id为1,6,10三条数据。

步骤 会话A 会话B 会话C 备注
1 start transaction; start transaction; start transaction; 三方开启事务
2 select * from cs where id = 5 lock in share mode; INSERT INTO cs (id, num1, num2, s1, s2) VALUES (4, 1, 1, 'abc', 'xyz'); INSERT INTO cs (id, num1, num2, s1, s2) VALUES (4, 1, 1, 'abc', 'xyz'); 事务A上间隙锁，其余事务插入数据
3 / 阻塞 阻塞 间隙锁起作用阻塞B、C会话
4 commit; 成功插入 成功插入 插入意向锁起作用，让两个插入的事务不发生阻塞
5 commit; commit; commit; 提交事务，结束流程

页锁

页锁是一种锁定级别，用于控制对数据表中的页（MySQL对表数据读写的基本单位）的访问。 由于SQL语句层面，DDL、DML、DQL，都是针对库表或者表数据的读写操作，对于页极少操作，页锁粒度较大，其它锁范围使用场景够用，所以了解概念就行。

悲观锁

之前写过详细的文章可进行参考：MySQL乐观锁与悲观锁。

悲观锁比较悲观，假设数据一定会造成冲突，属于MySQL层面的锁。通过加锁阻塞其他事务，悲观锁可以保证在任何时刻，只有一个事务能够修改或访问共享资源，从而实现了强一致性。这意味着在悲观锁机制下，每个事务的读写操作都是有序、线性的。 需要事务的参与。

悲观锁，最经典的场景就是防超卖，一共10个库存，由于并发情况下，两个请求查询到的库存都是10，一个请求下单6个，一个请求下单8个，如果不加锁使其在事务中阻塞（阻塞可以理解为强制让事务串行执行），那就会有超卖的情况发生，即使是超卖，库存也不会显示为负，因为并发情况下两个请求检测到的库存都是10,大于8和6，最终扣库存的结果不是10-8-6=-4（这是串行请求的理论值），而是2或者4。

适用场景 写多写操作的前提，是保证数据不出错，悲观锁的机制很符合。

优点

  • 强一致性：基于事务又加锁，一致性可以保证。
  • 实现简单：在事务中for update即可，开发者不需要在这上面关注太多。

缺点

  • 死锁风险：悲观锁在使用不当的情况下可能导致死锁。如果多个事务持有锁并相互等待对方释放锁的情况发生，就可能发生死锁。
  • 性能较低：悲观锁通常需要在整个事务过程中锁定资源，这可能导致其他事务阻塞。

简单测试：模拟并发情况下防超卖，假设cs表的num1字段为库存字段

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 select num1 from cs where id = 1 for update; update cs set num1 = num1 - 6 where id = 1 and num1 >= 6; select num1 from cs where id = 1 for update; update cs set num1 = num1 - 8 where id = 1 and num1 >= 8; 双方添加X行锁，并准备扣减库存
3 / 阻塞 此时必有一个事务阻塞，等这个事务扣完库存提交事务后，在执行另一个扣库存的事务
4 commit; commit; 双方提交事务，双方代码执行成功，但会话B库存不足，最终剩余库存4，结束流程

注意，实际的开发逻辑，与以上示例况有偏差。 若前端检测到库存不足，直接拦截用户的下单动作并提示，就不会有后端的流程。 若前端认为库存充足，后端可能是下单时预扣库存，预扣库存的环节提前就检测当前其库存是否够当前的购买数量，若不够，则直接终止流程，返回用户结果。 若库存够用但未支付，若超时30分钟未支付则取消订单（这个延时队列可以用Redis Zset 或者RabbitMQ等其它消息中间件实现），若支付，则算一笔成功的交易。 这是MySQL能抗住的情况，如果抗不住，就需要Redis+Lua的单线程事务来阻止超卖的发生。

乐观锁

之前写过详细的文章可进行参考：MySQL乐观锁与悲观锁

乐观锁很乐观，假设数据一般情况不会造成冲突，属于程序层面的逻辑锁，在数据进行更新时，才进行锁的检测。是通过添加一个版本号的方式实现的，每当数据这一行所在的数据发生变化，则对应的版本号+1，更新数据时，将版本号作为查询条件。 至于是否要加事务，看写操作单条数据还是写操作多条数据。

注意：网上很多解决方案用时间戳来做version字段，我持反对意见，并发可能是一瞬间的事，不到一秒就有好多请求，用时间戳粒度太大，用随机字符串都比用这个强。

适用场景

  • 读多写少：由于并发写操作较少，乐观锁的修改数据受影响行数为0概率也较低。 允许一定量的重试或不需要重试的场景：这个要根据业务，否则来回重试会降低性能。 优点
  • 实现简单：乐观锁在代码上就可以实现，不需要额外对数据库额外操作。
  • 无死锁风险：悲观锁有死锁风险，乐观锁没有。 无需重试情况下，性能较高：乐观锁机制在并发访问情况下，不需要像悲观锁那样阻塞其他事务，提供了更高的并发性能，前提当前业务需求能容忍写操作失败的情况。

缺点

  • 并发冲突：多加了一个where条件，只能保证数据最终不会出错，不能保证每条写操作的SQL都执行成功（也就是受影响行数>0）。
  • 不提供强一致性：强一致性要求数据的状态在任何时刻都保持一致，悲观锁是到写操作那一步才去验证，期间只是做了个where条件的过滤。
  • ABA问题：一个字段的值在请求X中查询出来是A，后续代码实现乐观锁，因为并发量大，同时过来一个Y请求，将A值改成了B，因为一些业务原因又改成了A，整个过程虽然不影响请求X的结果，且能正常执行，但是联合其它数据，这个情况是否符合业务场景，不好说，所以最好的解决方案，就是专门做一个version字段，且不会与之前的version重复，即可，把这个version字段作为where条件，而不是存A或者B字段的所在字段作为where条件。
  • 当前的请求中了上一个乐观锁的招，导致的版本号不一样，需要重试，反复的重试也降低性能，由于这个原因，所以用于读操作多的场景。

简单测试：模拟并发情况下防超卖，假设cs表的num1字段为库存字段，s1为version字段，一共10个库存，两个请求查询到的库存都是10，一个请求下单6个，一个请求下单8个。

步骤 会话A 会话B 备注
1 select * from cs where id = 1 select * from cs where id = 1 双方获取版本号和库存
2 update cs set num1 = num1 - 6,s1 = 'version2' where id = 1 and s1 = 'version1' and num1 >=6; update cs set num1 = num1 - 8,s1 = 'version1' where id = 1 and s1 = 'version1' and num1 >=8; 乐观锁无需事务，但是需要多个原子性的业务场景，仍推荐加事务
3 扣库存成功 虽然是并发场景，但A执行略快于B，此时版本号已修改为version2 会话B执行成功，但库存扣减失败
4 / select * from cs where id = 1 会话B进行重试，并重新获取版本号和库存
5 / update cs set num1 = num1 - 8,s1 = 'version3' where id = 1 and s1 = 'version2' and num1 >=8; 双方代码执行成功，但会话B库存不足，最终剩余库存4，结束流程

隐式锁

隐式锁不需要显式地编写锁定关键词，会自动加锁或解锁。 例如在未提交的事务中插入数据，就是通过隐式锁的方式避免其它事务对插入数据的读写，如果能读到了那就是脏读，如果能写那就是脏写。 隐式锁是一种延时加载的方式，在多个事务的情况下，在第二个事务访问时，才会被动的加锁，这样可以减少锁的数量。 由于不需要手动处理，了解机制就行。

步骤 会话A 会话B 会话C 备注
1 start transaction; start transaction; SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; AB开启事务，C检测锁
2 insert into cs(num1, num2, s1, s2) values(1,2,3,4); / SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; A插入数据，此时C未检测到有锁
3 / select * from cs lock in share mode; SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; insert操作会产生一个写锁，进而阻止事务B的读锁，此时事务C可以查看的到
4 / 阻塞 / 在第二个事务访问时，事务A被动的加锁，通过事务C可以查看的到
5 commit; commit; / 双方提交事务，会话A成功插入一条数据

显式锁

显式声明的锁，for update，lock in share mode这种的。

全局锁

全局锁（Global Lock）的作用是锁定整个数据库实例，让整个库只能读不能写，粒度很大。 flush tables with read lock：获取全局读锁，对所有事务只能读不能写。 unlock tables：释放全局锁。 应用场景：备份数据库或者导出数据时，为了保证数据的一致性而需要锁定整个数据库实例，确保备份过程中数据不会发生变化。全局锁会影响数据库的正常运行。 测试：

步骤 会话A 会话B 备注
1 flush tables with read lock; / 会话A开启全局锁
2 / select * from cs; desc cs; 读数据表和表数据都没问题
3 / insert into cs(num1, num2, s1, s2) values(1,2,3,4); 会话B插入数据
4 / 阻塞 全局锁禁止写操作
5 unlock tables; 插入成功 释放全局锁。数据插入成功
6 flush tables with read lock; / 会话A开启全局锁
7 / alter table cs add index(num1); 会话B为表字段加索引
8 / 阻塞; 全局锁阻塞DDL操作
9 unlock tables; 索引添加成功 释放全局锁，索引插入成功，结束会话

死锁

之前写过关于死锁的详细文章：MySQL死锁。 MySQL 中的死锁是指两个或多个事务相互等待对方释放锁资源，导致它们永远无法继续执行的情况。（不会耕田,怎能下地 不会下地,怎么耕田） 测试：先cs表中有id为1,6的两条数据

步骤 会话A 会话B 备注
1 start transaction; start transaction; 双方开启事务
2 update cs set num1 = 1 where id = 1; update cs set num1 = 60 where id = 6; 更新数据默认会产生X锁，这一步正常执行
3 update cs set num1 = 6 where id = 6; update cs set num1 = 10 where id = 1; 更新数据默认会产生X锁
4 阻塞 / 事务B对于id=6的写锁并未释放，此时又新增了update请求，需要加X锁，所以阻塞
5 / Deadlock found when trying to get lock; try restarting transaction 事务AB互相需要等待，导致死锁
6 commit; commit; 双方提交事务，结束流程，事务A正确执行，事务B被回滚

排查方法1

sql 复制代码 
show engine innodb status;

执行以上命令会得到大量日志，在LATEST DETECTED DEADLOCK与TRANSACTIONS之间寻找sql 语句，以此定位死锁源头。示例如下：

sql 复制代码 
......
------------------------
LATEST DETECTED DEADLOCK
------------------------
2024-01-23 23:48:30 0x1f00
*** (1) TRANSACTION:
TRANSACTION 805714, ACTIVE 12 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 3, OS thread handle 8076, query id 762 localhost ::1 root updating
update test set name = 'C++语言' where id = 2
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2575 page no 3 n bits 72 index PRIMARY of table `temp`.`test` trx id 805714 lock_mode X locks rec but not gap waiting
Record lock, heap no 6 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
 0: len 4; hex 00000002; asc     ;;
 1: len 6; hex 0000000c4b53; asc     KS;;
 2: len 7; hex 34000002a80923; asc 4     #;;
 3: len 3; hex 432b2b; asc C++;;

*** (2) TRANSACTION:
TRANSACTION 805715, ACTIVE 9 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 4, OS thread handle 7936, query id 766 localhost ::1 root updating
delete from test where id = 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 2575 page no 3 n bits 72 index PRIMARY of table `temp`.`test` trx id 805715 lock_mode X locks rec but not gap
Record lock, heap no 6 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
 0: len 4; hex 00000002; asc     ;;
 1: len 6; hex 0000000c4b53; asc     KS;;
 2: len 7; hex 34000002a80923; asc 4     #;;
 3: len 3; hex 432b2b; asc C++;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2575 page no 3 n bits 72 index PRIMARY of table `temp`.`test` trx id 805715 lock_mode X locks rec but not gap waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 00000001; asc     ;;
 1: len 6; hex 0000000c4b46; asc     KF;;
 2: len 7; hex ad000002b10110; asc        ;;
 3: len 1; hex 43; asc C;;

*** WE ROLL BACK TRANSACTION (1)
------------
TRANSACTIONS
------------
Trx id counter 805727
Purge done for trx's n:o < 805727 undo n:o < 0 state: running but idle
History list length 36
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 283132143509864, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283132143508992, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283132143508120, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283132143507248, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
......

排查方法2

sql 复制代码 
show status like 'innodb_row_lock%'

执行以上命令后会得到一个表格，

sql 复制代码 
Innodb_row_lock_current_waits	0    如果这个数字非零，表示有事务正在等待其他事务持有的行级锁。
Innodb_row_lock_time	       18756 以毫秒为单位。它表示所有事务在竞争锁资源时，所消耗的总时间
Innodb_row_lock_time_avg	   3126  平均每个InnoDB行级锁的持有时间，毫秒为单位。用总的锁持有时间除以锁请求次数来计算。
Innodb_row_lock_time_max	   7921  单个InnoDB行级锁的最大持有时间，毫秒为单位。这个值表示所有事务竞争锁资源中的最长时间。
Innodb_row_lock_waits      	   6     这个指标表示有多少次事务在竞争锁资源时需要等待。

排查方法3 该查询是用来获取当前正在运行的事务（INNODB_TRX表）、空闲状态的线程（PROCESSLIST表，COMMAND为Sleep）、线程对应的进程信息（threads表）、线程对应的当前执行中的SQL语句（events_statements_current表）的一些相关信息。

sql 复制代码 
SELECT a.trx_id, a.trx_state, a.trx_started, a.trx_query, b.ID, b.USER, b.DB, b.COMMAND, b.TIME, b.STATE, b.INFO, c.PROCESSLIST_USER, c.PROCESSLIST_HOST, c.PROCESSLIST_DB, d.SQL_TEXT 
FROM information_schema.INNODB_TRX a
LEFT JOIN information_schema.PROCESSLIST b ON a.trx_mysql_thread_id = b.id AND b.COMMAND = 'Sleep'
LEFT JOIN performance_schema.threads c ON b.id = c.PROCESSLIST_ID
LEFT JOIN performance_schema.events_statements_current d ON d.THREAD_ID = c.THREAD_ID;

解决 MySQL会自动解决死锁问题，代价就是MySQL自行找到成本最低的事务，自动回滚。所以说解决方案不是解锁，而是避免。

避免

  • 降低事务粒度：轻量级的事务，锁定更少的资源，不容易发生死锁。
  • 尽快提交事务：锁能更快的释放。
  • 合理的索引设计: 合理设计数据库表的索引可以减少锁竞争，提高查询效率。
  • 一致的访问顺序: 当应用程序涉及多个表时，保持一致的访问顺序可以避免死锁。例如，如果事务A先锁定表X，再锁定表Y，那么事务B也应该按照相同的顺序锁定表X和表Y，从而避免死锁。

什么是最小成本回滚策略？ 在 MySQL 中，当发生死锁时，MySQL 使用一种叫做"最小成本回滚"（InnoDB 中称为"最小编号事务回滚"）的策略来选择一个事务作为牺牲者并进行回滚，最小成本回滚策略是 MySQL 的默认行为，它会自动选择牺牲者并回滚事务。 最小成本回滚策略的原理是选择最小成本的事务作为牺牲者。评估算法如下：

  • 回滚事务所涉及的操作数量：回滚操作的数量越小，成本越低。
  • 回滚事务所占用的系统资源：回滚事务占用的系统资源越少，成本越低。
  • 回滚事务已执行的工作量：已执行的工作量越少，成本越低。

锁排查与监控

查询语句用于查看 InnoDB 存储引擎中关于行锁的相关统计信息

sql 复制代码 
show status like 'innodb_row_lock%';

Innodb_row_lock_current_waits  如果这个数字非零，表示有事务正在等待其他事务持有的行级锁。
Innodb_row_lock_time	       以毫秒为单位。它表示所有事务在竞争锁资源时，所消耗的总时间
Innodb_row_lock_time_avg	   平均每个InnoDB行级锁的持有时间，毫秒为单位。用总的锁持有时间除以锁请求次数来计算。
Innodb_row_lock_time_max	   单个InnoDB行级锁的最大持有时间，毫秒为单位。这个值表示所有事务竞争锁资源中的最长时间。
Innodb_row_lock_waits      	   这个指标表示有多少次事务在竞争锁资源时需要等待。

查看 InnoDB 存储引擎中当前活动的事务信息

sql 复制代码 
SELECT * FROM information_schema.innodb_trx;

trx_id                         事务的唯一标识符。
trx_state                      事务的状态，如 RUNNING、LOCK WAIT、ROLLING BACK 等。
trx_started                    事务启动的时间。
trx_requested_lock_id          请求的锁的标识符。
trx_wait_started               等待锁的开始时间。
trx_weight                     事务的权重，用于死锁检测。
trx_mysql_thread_id            MySQL 线程 ID。
trx_query                      与事务相关的 SQL 查询语句。
trx_operation_state            事务内部操作的状态。
trx_tables_in_use              事务使用的表的数量。
trx_tables_locked              事务锁定的表的数量。
trx_lock_structs               事务内部使用的锁结构数量。
trx_lock_memory_bytes          用于事务锁定的内存字节数。
trx_rows_locked                事务锁定的行数。
trx_rows_modified              事务修改的行数。
trx_concurrency_tickets        用于事务并发控制的票数。
trx_isolation_level            事务的隔离级别。
trx_unique_checks              是否启用了唯一性检查。
trx_foreign_key_checks         是否启用了外键约束检查。
trx_last_foreign_key_error     最后一个外键错误信息。
trx_adaptive_hash_latched      是否适应性哈希被锁定。
trx_adaptive_hash_timeout      适应性哈希锁定超时次数。
trx_is_foreign_key_with_check  是否用于外键约束检查。
trx_is_foreign_key             是否用于外键约束。

查看 InnoDB 存储引擎中当前正在被锁定的对象（如表、行）的信息

sql 复制代码 
SELECT * FROM information_schema.innodb_locks;

lock_id      锁的唯一标识符。
lock_trx_id  持有该锁的事务的唯一标识符。
lock_mode    锁的模式，如 S（共享锁）或 X（独占锁）等。
lock_type    锁的类型，如 RECORD（行级锁）或 TABLE（表级锁）等。
lock_table   被锁定的表名。
lock_index   被锁定的索引名。
lock_space   被锁定的表空间的标识符。
lock_page    被锁定的页码。
lock_rec     锁定的记录。
lock_data    与锁相关的其他数据。

查看 InnoDB 存储引擎中当前存在的锁等待情况

sql 复制代码 
SELECT * FROM information_schema.innodb_lock_waits;

requesting_trx_id   请求锁的事务的唯一标识符。
requested_lock_id   请求的锁的唯一标识符。
blocking_trx_id     导致锁等待的阻塞事务的唯一标识符。
blocking_lock_id    导致锁等待的锁的唯一标识符。
相关推荐
waicsdn_haha几秒前
Java/JDK下载、安装及环境配置超详细教程【Windows10、macOS和Linux图文详解】
java·运维·服务器·开发语言·windows·后端·jdk
良许Linux15 分钟前
0.96寸OLED显示屏详解
linux·服务器·后端·互联网
ThisIsClark19 分钟前
【后端面试总结】MySQL主从复制逻辑的技术介绍
mysql·面试·职场和发展
蜜獾云26 分钟前
docker 安装雷池WAF防火墙 守护Web服务器
linux·运维·服务器·网络·网络安全·docker·容器
小屁不止是运维27 分钟前
麒麟操作系统服务架构保姆级教程（五）NGINX中间件详解
linux·运维·服务器·nginx·中间件·架构
Hacker_Oldv32 分钟前
WPS 认证机制
运维·服务器·wps
bitcsljl40 分钟前
Linux 命令行快捷键
linux·运维·服务器
Mr.131 小时前
数据库的三范式是什么？
数据库
Cachel wood1 小时前
python round四舍五入和decimal库精确四舍五入
java·linux·前端·数据库·vue.js·python·前端框架
Python之栈1 小时前
【无标题】
数据库·python·mysql
热门推荐
01〔AI 绘画〕Stable Diffusion 之 解决绘制多人或面部很小的人物时面部崩坏问题 篇02ARM学习（31）编译器对overlay方式的支持03玄机平台应急响应—webshell查杀04DisplayPort AltMode On Type-c协议_Ver2.0(学习笔记)05校验 GPT-4 真实性的三个经典问题：快速区分 GPT-3.5 与 GPT-4，并提供免费测试网站06Docker 夺命连环 15 问076个主流的工业3D管道设计软件08基于大语言模型（LLM）的合成数据生成、策展和评估的综述09(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明10红米手机使用google play