Mysql 锁机制分析

news2024/9/20 20:29:36

整体业务代码精简逻辑如下：

@Transaction
public void service(Integer id) {
    delete(id);
    insert(id);
}

数据库实例监控：

当时通过分析上游问题流量限流解决后，后续找时间又重新分析了下问题发生的根本原因，现将其总结如下：本篇文章会先对 Mysql 中的各种锁进行分析，包括互斥锁、间隙锁和插入意向锁，让大家对各种锁的使用场景有一个了解，然后在此基础上再对本问题进行分析，希望大家未来再碰到相似场景时，能够快速的定位问题

Mysql 锁机制

在 Mysql 中为了解决对同一行记录并发写的问题，引入了行锁机制，多个事务不能同时对一行数据进行修改操作，当需要对数据库中的一行数据进行修改时，会首先判断该行数据是否加锁，如果没加锁，那么当前事务加锁成功，可以进行后续的修改操作；但如果该行数据已经被其他事务加锁，则当前事务只有等待加锁的事务释放锁后才能加锁成功，继续执行修改操作

本篇文章中所有实验用到的建表语句：

create table `test` (
    `id` int(11) NOT NULL,
    `num` int(11) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `num` (`num`)
) ENGINE = InnoDB;

insert into
    test
values
(10, 10),
(20, 20),
(30, 30),
(40, 40),
(50, 50);

Shared and Exclusive Locks

shared(S) lock 表示共享锁，当一个事务持有某行上的 S 锁后可以对该行的数据进行读操作，通过语句 select ... from test lock in share mode 可以添加共享锁，一般使用的较少，不做过多阐述

exclusive(X) lock 表示互斥锁，当一个事务对某行数据进行 update 或 delete 操作时都要先获取到该记录上的 X 锁，如果已经有其他事务获取到了该记录上的 X 锁，那么当前事务会阻塞等待直到上一事务释放了对应记录上的 X 锁

S 锁之间不互斥，多个事务可以同时获取一条记录上的 S 锁 X 锁之间互斥，多个事务不能同时获取同一条记录上的 X 锁 S 锁和 X 锁之间互斥，多个事务不能同时获取同一条记录上的 S 锁和 X 锁

当多个事务同时去 update 索引上同一条记录时，都需要先获取到该记录上的 X 锁，所谓的锁也就是会在内存中生成一个数据结构来记录当前的事务信息、锁类型和是否等待等信息。下图中就是 T1 和 T2 同时去更新 id = 30 的这行记录，并且 T1 成功获取到了锁，其在内存中生成的锁结构信息中字段 is_wating 为 false，可以继续执行事务的后续逻辑，而 T2 获取锁失败，则生成的锁结构信息字段 is_wating 为 true，阻塞等待 T1 上的锁释放

互斥锁在 Mysql 日志中的锁信息为：lock_mode X locks rec but not gap

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`
trx id 10078 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 8000000a; asc     ;;
 1: len 6; hex 00000000274f; asc     'O;;
 2: len 7; hex b60000019d0110; asc        ;;

Gap Locks

上一小节中介绍了 Exclusive Locks，该锁可以避免多个事务同时对一行记录进行更新操作，但不能解决幻读的问题，所谓的幻读就是指一个事务在前后两次查询同一个范围时，后一次查询到了前一次没有的记录

session Asession B
T1select num from test where num > 10 and num < 15 for update; (0 rows)
T2insert into test values(12, 12);
T3select num from test where num > 10 and num < 15 for update; (1 rows)

在上面这个场景中，session A 分别在 T1、T3 时刻进行了两次范围查询，session B 在 T2 时刻插入了一条该范围内的数据，如果 session A 能在 T3 时刻查询出 session B 插入的数据，就说明发生了幻读。此时只使用互斥锁是无法解决幻读的，因为 num = 12 的记录在数据库中还不存在，不能给其加上互斥锁来防止 T2 时刻 session B 的插入

因此为了解决幻读问题，只有引入新的锁机制，也就是间隙锁(Gap Locks)。间隙锁和互斥锁不同，互斥锁是行锁，只会锁定一行特定的记录，而间隙锁则是锁定两行记录之间的空隙，防止其他事务在此间隙中插入新的记录

引入了间隙锁之后，session A 在 T1 时刻会给 id = 20 记录生成一个 Gap Locks，之后 session B 在 T2 时刻想要插入记录时，需要先判断待插入位置的后一条记录上是否存在 Gap Locks，很明显此时 id = 20 的记录上已经存在了 Gap Locks，那么session B 就需要在 id = 20 的记录上生成一个插入意向锁，并进入锁等待

间隙锁在 Mysql 中的锁日志信息如下：lock_mode X locks gap before rec

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38849 lock_mode X locks gap before rec
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 8000001e; asc     30 ;;
 1: len 6; hex 00000000969c; asc       ;;
 2: len 7; hex a60000011a0128; asc       (;;
 3: len 4; hex 8000001e; asc     ;;

间隙锁虽然解决了幻读问题，但因每次都会锁住一段间隙，大大降低了数据库整体的并发度，且因间隙锁和间隙锁之间不互斥，不同事务可以同时对同一间隙加上 Gap Locks，这也往往是各种死锁产生的源头

Next-Key Locks

Next-Key Locks 是 (Shard/Exclusive Locks + Gap Locks) 的结合，当 session A 给某行记录 R 添加了互斥型的 Next-Key Locks 后， 相当于拥有了记录 R 的 X 锁和记录 R 的 Gap Locks

在上面 Gap Locks 的例子中事务 1 加的就是 Next-Key Locks，即同时给 id = 20 的记录加了 X 锁和 Gap 锁

在可重复读隔离级别下，update 和 delete 操作默认都会给记录添加 Next-Key Locks，Mysql 中 Next-Key Locks 的锁日志信息为：lock_mode X

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`
trx id 10080 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 8000000a; asc     ;;
 1: len 6; hex 00000000274f; asc     'O;;
 2: len 7; hex b60000019d0110; asc        ;

Insert Intention Locks

插入意向锁(Insert Intention Locks) 也是一种间隙锁，由 INSERT 操作在行数据插入之前获取

在插入一条记录前，需要先定位到该记录在 B+ 树中的存储位置，然后判断待插入位置的下一条记录上是否添加了 Gap Locks，如果下一条记录上存在 Gap Locks，那么插入操作就需要阻塞等待，直到拥有 Gap Locks 的那个事务提交，同时执行插入操作等待的事务也会在内存中生成一个锁结构，表明有事务想在某个间隙中插入新记录，但目前处于阻塞状态，生成的锁结构就是插入意向锁

实验模拟如下：

session 1session 2session 3
T1begin;
T2select * from test where id = 25 for update;
T3insert into test values(26, 26); (blocked)
T4insert into test values(26, 26); (blocked)

对于语句 select * from test where id = 25 for update 因当前表中不存在该记录，在可重复读隔离级别下，为了避免幻读，会给 (20, 30] 间隙加上 Gap Locks

从锁日志可以看出 session 1 给记录 30 添加了间隙锁(lock_mode X locks gap before rec)

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38849 lock_mode X locks gap before rec
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 8000001e; asc     30 ;;
 1: len 6; hex 00000000969c; asc       ;;
 2: len 7; hex a60000011a0128; asc       (;;
 3: len 4; hex 8000001e; asc     ;;

当 session 2 插入记录 26 时，会在 B+ 树中先定位到待插入位置，再判断插入位置的间隙是否存在 Gap Locks，也就是判断待插入位置的后一记录 id = 30 是否存在 Gap Locks，如果存在需要在该记录上生成插入意向锁等待

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38850 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 8000001e; asc    30 ;;
 1: len 6; hex 00000000969c; asc       ;;
 2: len 7; hex a60000011a0128; asc       (;;
 3: len 4; hex 8000001e; asc     ;;

此时 session 2 和 session 3 都在 id = 30 的记录上添加了插入意向锁等待 session 1 上的 Gap Locks 释放，生成的锁记录如下：

线上问题分析

在对 Mysql 中的各种锁结构有了一个清晰的了解之后，回过头来再看看前面的线上问题

@Transaction
public void service(Integer id) {
    delete(id);
    insert(id);
}

对于上面的业务代码可能存在下面两种情况:

  • 传入的参数 id 在原数据库中不存在
  • 传入的参数 id 在原数据库中存在

本次主要会针对 id 记录在原数据库中不存在进行分析

session 1session 2session 3
T1delete from test where id = 15;
T2delete from test where id = 15;delete from test where id = 15;
T3insert into test values(15, 15);
T4insert into test values(15, 15);
T5insert into test values(15, 15);

因 id = 15 在数据库中不存在，在 T1 时刻 session 1 会给其所在间隙的下一条记录添加上 Gap Locks，又因 Gap Locks 不互斥， 在 T2 时刻 session 2 和session 3 都会同时获取到 id = 20 的 Gap 锁

下图中 tx: T1、T2、T3 分别代表 session 1、session 2 和 session 3

当在 T3 时刻 session 1 插入 id = 15 的记录时，会判断其插入位置的后一条记录是否存在 Gap Locks，如果存在，则需要在该记录上生成 Insert Intention Locks 并等待持有 Gap Locks 的事务释放锁

在 T4 时刻 session 2 执行插入语句，同样会因插入位置的后一条记录中存在 Gap Locks 而需要生成 Insert Intention Locks 等待。此时很明显就形成了死锁，session 1 生成插入意向锁等待 session 2 和 session 3 上的 Gap 锁释放，而 session 2 同样生成插入意向锁等待 session 1 和 session 3 上的 Gap 锁释放

在 T4 时刻检测到死锁后，Mysql 会选择其中一个事务进行回滚，假设此时 session 2 被回滚，释放了其持有的所有锁资源，session 1 可以继续执行吗？ 很明显不可以，session 1 还同时在等待 session 3 上的 Gap 锁释放，继续阻塞等待

在 T5 时刻 session 3 开始执行插入语句，此时同 T4 时刻，死锁形成，session 1 生成的插入意向锁正在等待 session 3 上的 Gap Locks 释放，session 3 上生成的插入意向锁正在等待 session 1 上的 Gap Locks 释放，此时 session 3 回滚释放所有锁资源后，session 1 才可以最终执行成功

在完成了三个并发线程的死锁分析后，可能有人会想虽然有死锁，但通过死锁检测可以很快的检测出，程序也可以正常的执行，这有什么问题呢？ 其实上面没有问题主要是因为并发量较小，死锁检测可以很快检测出，如果此时将并发量扩大 100 倍甚至 1000 倍后，还会没有问题吗？

看看当时出现线上问题时，接口的调用量情况，

进一步在本地模拟 300 个线程并发执行，因人脑并发分析所有事务的执行情况的话会非常复杂，本次只以事务 1 为一个点来进行分析

从图中可以看到当 T1 在执行插入语句时，需要等待 T2- T101 上持有的 Gap Locks 释放，之后 T2 - T6 可能同时执行插入语句，然后进行死锁检测，事务回滚，看着似乎只要后续有事务执行了插入语句就会执行死锁回滚，正常运行，但在死锁检测的过程中还会有新事务(T101 - T 200 )获取到 Gap Locks，造成锁等待队列中的事务越来越多，而 Mysql 的整体死锁检测时间复杂度为 O(n^2)，锁等待队列中的事务较多时，每一次有新事务进行锁等待，死锁检测都需要遍历锁等待队列中在其之前等待的事务，判断是否会因自己的加入形成环，此时检测会非常消耗 CPU 资源，造成数据库整体性能下降，死锁检测耗时增加，Mysql 活跃连接数大幅增加，并且因锁等待而连接无法释放，最终造成应用层连接池被打满

综上分析，本次出现问题的最主要原因是在短时间内存在大并发的请求对同一行数据进行先删除再插入操作(先更新再插入同理)，造成了死锁等待，应用层连接池被打满，大量上游请求超时重试，进一步导致锁等待，最终影响了所有依赖该数据库的业务

因此对于未来在业务代码中存在相似逻辑的地方，一定要做好防重校验，避免短时间内存在对同一行数据的先更新再插入的并发操作。同时在可重复读隔离别下，更新和删除操作默认都会添加 Next-Key Locks，间隙锁的引入使得死锁问题在并发情况下很容易出现，这也是在业务逻辑实现上需要考虑的问题。

总结

本文以一个线上问题为背景，对 Mysql 中的各种锁机制进行了详细的总结，分析了各个锁的加锁时机和具体使用场景，其中特别要注意间隙锁的使用，因间隙锁和间隙锁之间不互斥，当多个事务之间并发执行时很容易形成死锁

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1245556.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

使用端口扫描工具解决开放端口威胁并增强安全性

使用端口扫描工具解决开放端口威胁并增强安全性

从暴露网络漏洞到成为入侵者的通道&#xff0c;开放端口可能会带来多种风险向量&#xff0c;威胁到网络的机密性、完整性和可用性。因此&#xff0c;最佳做法是关闭打开的端口&#xff0c;为了应对开放端口带来的风险&#xff0c;网络管理员依靠端口扫描工具来识别、检查、分析…
阅读更多...
JS中的OOP

JS中的OOP

JS中的OOP OOP 为我们解决了什么问题&#xff1f;想象一下&#xff0c;我们希望为教师提供一个平台&#xff0c;每位注册的教师都可以提交分数&#xff0c;并为课程分配作业和其他内容。 如果有一个地方&#xff08;在本例中是一个对象&#xff09;&#xff0c;可以访问所有教…
阅读更多...
uboot中nfs和tftp方式获取文件

uboot中nfs和tftp方式获取文件

NFS文件系统挂载 服务器端配置如下 1.Server端需要安装NFS服务&#xff1a; sudo apt-get install nfs-kernel-server2.创建需要挂载的路径&#xff1a; mkdir -p /home/workspace/mercury/nfs_path3.创建共享目录&#xff1a; ①vim /etc/exports ②在文件中添加&#xff…
阅读更多...
合并两个有序链表，剑指offer,力扣

合并两个有序链表，剑指offer,力扣

目录 力扣题目地址&#xff1a; 原题题目&#xff1a; 我们直接看题解吧&#xff1a; 解题方法&#xff1a; 审题目事例提示&#xff1a; 解题思路&#xff1a; 具体流程如下&#xff1a; 代码实现&#xff1a; 知识补充&#xff1a; 力扣题目地址&#xff1a; 21. 合并两个有序…
阅读更多...
git查看某个commit属于哪个分支方法(如何查看commit属于哪个分支)

git查看某个commit属于哪个分支方法(如何查看commit属于哪个分支)

有时候&#xff0c;当我们由于业务需求很多时&#xff0c;基于同一个分支新建的项目分支也会很多。 在某个时间节点&#xff0c;我们需要合并部分功能点时&#xff0c;我们会忘了这个分支是否已经合入哪个功能点&#xff0c;我们就会查看所有的commit记录&#xff0c;当我们找到…
阅读更多...
2024-NeuDS-数据库题目集

2024-NeuDS-数据库题目集

一.判断题 1.在数据库中产生数据不一致的根本原因是冗余。T 解析&#xff1a;数据冗余是数据库中产生数据不一致的根本原因&#xff0c;因为当同一数据存储在多个位置时&#xff0c;如果其中一个位置的数据被修改&#xff0c;其他位置的数据就不一致了。因此&#xff0c;在数据…
阅读更多...
GPIO HAL库+CubeMX

GPIO HAL库+CubeMX

以正点原子精英版为例&#xff1a; 一.创建HAL库模块 二.GPIO输出 1.自己编写 void led_init(void) {GPIO_InitTypeDef gpio_init_struct;__HAL_RCC_GPIOB_CLK_ENABLE();gpio_init_struct.Pin GPIO_PIN_5;gpio_init_struct.Mode GPIO_MODE_OUTPUT_PP;gpio_init_struct.Spee…
阅读更多...
linux -系统通用命令查询

linux -系统通用命令查询

有时候内网环境下&#xff0c;系统有些命令没有安装因此掌握一些通用的linux 命令也可以帮助我们解决一些问题查看 1.查看系统内核版本 uname -r2.查看系统版本 cat /etc/os-release3. 查看cpu 配置 lscpu4.查看内存信息 free [参数] 中各个数值的解释如下表 数值解释t…
阅读更多...
玻色量子“揭秘”之可满足性问题（SAT）与QUBO建模

玻色量子“揭秘”之可满足性问题（SAT）与QUBO建模

​ 摘要&#xff1a;布尔可满足性问题&#xff08;Boolean Satisfiability Problem&#xff0c;简称SAT问题&#xff09;是逻辑学和计算机科学中的一个问题&#xff0c;它的目的是确定是否存在一种解释&#xff0c;使给定的布尔公式成立。换句话说&#xff0c;它询问给定布尔公…
阅读更多...
OpenCV快速入门：图像分析——图像分割和图像修复

OpenCV快速入门：图像分析——图像分割和图像修复

文章目录 前言一、图像分割1.1 漫水填充法1.1.1 漫水填充法原理1.1.2 漫水填充法实现步骤1.1.3 代码实现 1.2 分水岭法1.2.1 分水岭法原理1.2.2 分水岭法实现步骤1.2.3 代码实现 1.3 GrabCut法1.3.1 GrabCut法原理1.3.2 GrabCut法实现步骤1.3.3 代码实现 1.4 Mean-Shift法1.4.1…
阅读更多...
面试题：为什么生产环境中，建议禁用 Redis 的 keys 命令？

面试题：为什么生产环境中，建议禁用 Redis 的 keys 命令？

keys命令的用法&#xff1a; keys pattern查找符合正则匹配的key的列表。扫描对象是Redis服务中所有的key&#xff0c;想想都很慢对不对&#xff1f; 同时执行keys命令的同时&#xff0c;Redis进程将被阻塞&#xff0c;无法执行其他命令&#xff0c;假如超过了哨兵的down-aft…
阅读更多...
Android系统预装带so的apk

Android系统预装带so的apk

文章目录 前言配置新建Android.mk核心命令首次编译Apk已生成 但是无arm文件system.img 也已经更新 第一次刷入打开APP后闪退加入so文件如下为修改后的mk 第二次刷入mm报错查看手机系统abi路径下分别生成两个环境的so官方LOCAL_MULTILIB描述so打包错误验证so位数注释v7部分 第三…
阅读更多...
界面组件DevExpress Reporting v23.1 - Web报表设计器功能升级

界面组件DevExpress Reporting v23.1 - Web报表设计器功能升级

DevExpress Reporting是.NET Framework下功能完善的报表平台&#xff0c;它附带了易于使用的Visual Studio报表设计器和丰富的报表控件集&#xff0c;包括数据透视表、图表&#xff0c;因此您可以构建无与伦比、信息清晰的报表 界面组件DevExpress Reporting v23.1已经发布一段…
阅读更多...
项目整个管理论文之5

项目整个管理论文之5

阅读更多...
图解分库分表

图解分库分表

中大型项目中&#xff0c;一旦遇到数据量比较大&#xff0c;小伙伴应该都知道就应该对数据进行拆分了。有垂直和水平两种。 垂直拆分比较简单&#xff0c;也就是本来一个数据库&#xff0c;数据量大之后&#xff0c;从业务角度进行拆分多个库。如下图&#xff0c;独立的拆分出…
阅读更多...
【PyQt】(自定义类)阴影遮罩

【PyQt】(自定义类)阴影遮罩

写了一个感觉有些用的小玩具。 用于给控件添加阴影遮罩(强调主控件的同时屏蔽其余控件的点击) 自定义阴影遮罩Mask&#xff1a; from PyQt5.QtCore import QPoint,QRect,Qt,QPoint,QSize from PyQt5.QtWidgets import QWidget,QLabel,QPushButton,QVBoxLayout from PyQt5.QtGu…
阅读更多...
Javaweb之前后台分离开发介绍的详细解析

Javaweb之前后台分离开发介绍的详细解析

2.1 前后台分离开发介绍 在之前的课程中&#xff0c;我们介绍过&#xff0c;前端开发有2种方式&#xff1a;前后台混合开发和前后台分离开发。 前后台混合开发&#xff0c;顾名思义就是前台后台代码混在一起开发&#xff0c;如下图所示&#xff1a; 这种开发模式有如下缺点&a…
阅读更多...
视频剪辑技巧：如何高效批量转码MP4视频为MOV格式

视频剪辑技巧：如何高效批量转码MP4视频为MOV格式

在视频剪辑的过程中&#xff0c;经常会遇到将MP4视频转码为MOV格式的情况。这不仅可以更好地编辑视频&#xff0c;还可以提升视频的播放质量和兼容性。对于大量视频文件的转码操作&#xff0c;如何高效地完成批量转码呢&#xff1f;现在一起来看看云炫AI智剪如何智能转码&#…
阅读更多...
基于STC12C5A60S2系列1T 8051单片读写掉电保存数据IIC总线器件24C02一字节并显示在液晶显示器LCD1602上应用

基于STC12C5A60S2系列1T 8051单片读写掉电保存数据IIC总线器件24C02一字节并显示在液晶显示器LCD1602上应用

基于STC12C5A60S2系列1T 8051单片读写掉电保存数据IIC总线器件24C02一字节并显示在液晶显示器LCD1602上应用 STC12C5A60S2系列1T 8051单片机管脚图STC12C5A60S2系列1T 8051单片机I/O口各种不同工作模式及配置STC12C5A60S2系列1T 8051单片机I/O口各种不同工作模式介绍IIC通信简单…
阅读更多...
【Java从入门到大牛】网络编程

【Java从入门到大牛】网络编程

&#x1f525; 本文由 程序喵正在路上 原创&#xff0c;CSDN首发&#xff01; &#x1f496; 系列专栏&#xff1a;Java从入门到大牛 &#x1f320; 首发时间&#xff1a;2023年11月23日 &#x1f98b; 欢迎关注&#x1f5b1;点赞&#x1f44d;收藏&#x1f31f;留言&#x1f4…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023