当前位置: 首页 > news >正文

MySQL INSERT 导致的死锁分析

前言

本文选用的 MySQL 版本:8.4.6

使用的数据

表结构:

DROP TABLE IF EXISTS store_snapshot_ext;
DROP TABLE IF EXISTS store_snapshot;create table store_snapshot
(id           varchar(32) not null comment '主键'primary key,warehouse_id varchar(32) null comment '仓库主键',snap_date    datetime    null comment '快照日期',create_id    varchar(32) null comment '创建人id',create_time  datetime    null comment '创建日期',modify_id    varchar(32) null comment '更新人 id',modify_time  datetime    null comment '更新时间'
)comment '仓库快照';create table store_snapshot_ext
(id             varchar(32) not null comment '主键'primary key,fk_snapshot_id varchar(32) null comment '快照外键',ext_attr       varchar(32) null comment '扩展属性',create_id      varchar(32) null comment '创建人id',create_time    datetime    null comment '创建日期',modify_id      varchar(32) null comment '更新人 id',modify_time    datetime    null comment '更新时间',constraint store_snapshot_ext___fk_snapshot_idforeign key (fk_snapshot_id) references store_snapshot (id)
)comment '仓库快照扩展属性';

这里使用 Java 语言模拟并发情况下对数据的插入:

import cn.hutool.core.date.DateTime;
import cn.hutool.core.util.RandomUtil;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit.jupiter.SpringExtension;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.TransactionDefinition;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.annotation.EnableTransactionManagement;
import org.springframework.transaction.support.DefaultTransactionDefinition;
import org.tea.common.entity.StoreSnapshot;
import org.tea.common.entity.StoreSnapshotExt;
import org.tea.common.mapper.StoreSnapshotExtMapper;
import org.tea.common.mapper.StoreSnapshotMapper;import javax.annotation.Resource;
import java.util.UUID;
import java.util.concurrent.CountDownLatch;@ExtendWith(SpringExtension.class)
@SpringBootTest(classes = StoreSnapshotApplication.class)
public class StoreSnapBenchTest {@Resourceprivate PlatformTransactionManager txManager;@Resourceprivate StoreSnapshotMapper storeSnapshotMapper;@Resourceprivate StoreSnapshotExtMapper storeSnapshotExtMapper;@Testpublic void batchTest() throws InterruptedException {Thread[] ts = new Thread[10];CountDownLatch startLatch = new CountDownLatch(1);CountDownLatch endLatch = new CountDownLatch(ts.length);for (int i = 0; i < ts.length; i++) {ts[i] = new Thread(() -> {DefaultTransactionDefinition definition = new DefaultTransactionDefinition();// 设置事务隔离级别为 "可重复读"definition.setIsolationLevel(TransactionDefinition.ISOLATION_REPEATABLE_READ);TransactionStatus status = txManager.getTransaction(definition);try {/**提高事务竞争的激烈度*/startLatch.await();/**一般情况下,不会使用如下的循环方式来插入数据,这里这么做的目的是为了提高事务的处理时间,增大锁的竞争激烈度*/for (int j = 0; j < 2000; j++) {StoreSnapshot snapshot = new StoreSnapshot();// 使用 UUID 的方式来引发 Page 分裂snapshot.setId(UUID.randomUUID().toString().replaceAll("-", ""));snapshot.setWarehouseId("warehouse_1");snapshot.setSnapDate(new DateTime());snapshot.init();storeSnapshotMapper.insertSelective(snapshot);StoreSnapshotExt snapshotExt = new StoreSnapshotExt();snapshotExt.setId(UUID.randomUUID().toString().replaceAll("-", ""));snapshotExt.setExtAttr(RandomUtil.randomString(32));// 注意这里的外键,后文会分析这个外键带来的一些影响snapshotExt.setFkSnapshotId(snapshot.getId());storeSnapshotExtMapper.insertSelective(snapshotExt);}txManager.commit(status);} catch (InterruptedException e) {txManager.rollback(status);throw new RuntimeException(e);} finally {endLatch.countDown();}});}for (Thread t : ts) {t.start();}startLatch.countDown();endLatch.await();}
}@SpringBootApplication
@EnableTransactionManagement
@MapperScan("org.tea.*.mapper")
class StoreSnapshotApplication {public static void main(String[] args) {SpringApplication.run(StoreSnapshotApplication.class, args);}
}

在执行完上面的测试用例后,查看 MySQL InnoDB 的状态信息,发现已经出现了死锁:

------------------------
LATEST DETECTED DEADLOCK
------------------------
2025-08-26 21:01:55 135637563962944
*** (1) TRANSACTION:
TRANSACTION 3866, ACTIVE 2 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 27 lock struct(s), heap size 8312, 220 row lock(s), undo log entries 430
MySQL thread id 17, OS thread handle 135637553456704, query id 8736 localhost ::1 root update
INSERT INTO store_snapshot (create_id, warehouse_id, snap_date, modify_id, id, modify_time, create_time)  VALUES  ('system', 'warehouse_1', '2025-08-26 21:01:54', 'system', '402ce43f650a483eb0c9c5138e50d6f0', '2025-08-26 21:01:54', '2025-08-26 21:01:54')*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 10 page no 11 n bits 240 index PRIMARY of table `lxh_db`.`store_snapshot` trx id 3866 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 00: len 8; hex 73757072656d756d; asc supremum;;*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 10 page no 20 n bits 160 index PRIMARY of table `lxh_db`.`store_snapshot` trx id 3866 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 9; compact format; info bits 00: len 30; hex 343033303963393162373166343731633936323164616565643434666363; asc 40309c91b71f471c9621daeed44fcc; (total 32 bytes);1: len 6; hex 000000000f14; asc       ;;2: len 7; hex 82000001070630; asc       0;;3: len 11; hex 77617265686f7573655f31; asc warehouse_1;;4: len 5; hex 99b7755074; asc   uPt;;5: len 6; hex 73797374656d; asc system;;6: len 5; hex 99b7755074; asc   uPt;;7: len 6; hex 73797374656d; asc system;;8: len 5; hex 99b7755074; asc   uPt;;*** (2) TRANSACTION:
TRANSACTION 3860, ACTIVE 3 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 46 lock struct(s), heap size 24696, 1258 row lock(s), undo log entries 2474
MySQL thread id 11, OS thread handle 135637890971200, query id 12330 localhost ::1 root update
INSERT INTO store_snapshot (create_id, warehouse_id, snap_date, modify_id, id, modify_time, create_time)  VALUES  ('system', 'warehouse_1', '2025-08-26 21:01:55', 'system', '917f3578682c467384e520fd6c00b86d', '2025-08-26 21:01:55', '2025-08-26 21:01:55')*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 10 page no 20 n bits 160 index PRIMARY of table `lxh_db`.`store_snapshot` trx id 3860 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 9; compact format; info bits 00: len 30; hex 336661623363323037333232346465666263363762333630363763623666; asc 3fab3c2073224defbc67b36067cb6f; (total 32 bytes);1: len 6; hex 000000000f14; asc       ;;2: len 7; hex 82000000932d80; asc      - ;;3: len 11; hex 77617265686f7573655f31; asc warehouse_1;;4: len 5; hex 99b7755076; asc   uPv;;5: len 6; hex 73797374656d; asc system;;6: len 5; hex 99b7755076; asc   uPv;;7: len 6; hex 73797374656d; asc system;;8: len 5; hex 99b7755076; asc   uPv;;Record lock, heap no 4 PHYSICAL RECORD: n_fields 9; compact format; info bits 00: len 30; hex 336664326234626538643463343338326130303764383431366364613536; asc 3fd2b4be8d4c4382a007d8416cda56; (total 32 bytes);1: len 6; hex 000000000f14; asc       ;;2: len 7; hex 82000000903800; asc      8 ;;3: len 11; hex 77617265686f7573655f31; asc warehouse_1;;4: len 5; hex 99b7755076; asc   uPv;;5: len 6; hex 73797374656d; asc system;;6: len 5; hex 99b7755076; asc   uPv;;7: len 6; hex 73797374656d; asc system;;8: len 5; hex 99b7755076; asc   uPv;;Record lock, heap no 5 PHYSICAL RECORD: n_fields 9; compact format; info bits 00: len 30; hex 343033303963393162373166343731633936323164616565643434666363; asc 40309c91b71f471c9621daeed44fcc; (total 32 bytes);1: len 6; hex 000000000f14; asc       ;;2: len 7; hex 82000001070630; asc       0;;3: len 11; hex 77617265686f7573655f31; asc warehouse_1;;4: len 5; hex 99b7755074; asc   uPt;;5: len 6; hex 73797374656d; asc system;;6: len 5; hex 99b7755074; asc   uPt;;7: len 6; hex 73797374656d; asc system;;8: len 5; hex 99b7755074; asc   uPt;;Record lock, heap no 93 PHYSICAL RECORD: n_fields 9; compact format; info bits 00: len 30; hex 336664396165326435663738346237656161346134323336643031643366; asc 3fd9ae2d5f784b7eaa4a4236d01d3f; (total 32 bytes);1: len 6; hex 000000000f14; asc       ;;2: len 7; hex 82000000a81784; asc        ;;3: len 11; hex 77617265686f7573655f31; asc warehouse_1;;4: len 5; hex 99b7755077; asc   uPw;;5: len 6; hex 73797374656d; asc system;;6: len 5; hex 99b7755077; asc   uPw;;7: len 6; hex 73797374656d; asc system;;8: len 5; hex 99b7755077; asc   uPw;;*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 10 page no 11 n bits 240 index PRIMARY of table `lxh_db`.`store_snapshot` trx id 3860 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 00: len 8; hex 73757072656d756d; asc supremum;;*** WE ROLL BACK TRANSACTION (1)
------------
TRANSACTIONS
------------

可以看到,在日志中,事务 3866 持有一个页号为 11supremum (相当于双链表的尾部哑节点) 的间隙锁,在等待页号为 20,主键为 40309c91b71f471c9621daeed44fcc 的间隙锁;同时,事务 3860 持有页号为 20,主键为 40309c91b71f471c9621daeed44fcc 的间隙锁,同时在等待页号为 10supremum 的间隙锁。这两个事务构成了循环回路,并且在相互等待,因此形成了死锁,具体的图示如下所示:

MySQL_DeadLock.jpg

具体分析

  1. 查询语句的加锁

    MySQL 的的一般 SELECT 语句在非串行化隔离级别下是通过一致性读的方式进行读取,本身不会对记录加锁,但是在存在外键约束的情况下,依旧会对关联的外键约束记录上加上 S 型的记录锁,如果关联的外键约束没有被找到,在"可重复读"的隔离级别下,会在外键记录附近加上间隙锁

    由于这里插入语句的外键都能被找到,因此这里的外键不是产生间隙锁的原因

  2. INSERT 语句的加锁

    单纯的 INSERT 语句在插入时加上的是一种特殊的记录锁,不同事务的插入意向锁不会相互阻塞,但是在插入的记录行的所处位置存在间隙锁的情况下,会为当前的 INSERT 记录加上 插入意向锁

    在主键重复的情况下,隔离级别为 "可重复读" 或 "串行化" 的情况下,会为插入的记录加上 S 型的 Next-Key 锁。在这种情况下,如果原来待插入行的事务回滚了,由于本身持有的 S 型锁无法再获取到独占锁,就有可能会引发死锁[2]

    由于这里的主键都是 UUID,不存在重复主键,并且结合相关的日志信息,并不是由于单纯的 INSERT 语句导致的死锁

  3. Page 的分裂

    当插入的记录的主键不连续时,MySQL 为了维护聚簇索引的顺序,可能会引发页的分裂。在事务隔离级别为 "可重复读"或"串行化" 的情况下,对分裂的数据进行迁移的过程中,相当于对数据执行了更新的操作,按照 MySQL 对于 UPDATE 语句的加锁情况[2],会在记录上加上 Next-Key (记录锁和间隙锁),因此事务 3860会持有记录40309c91b71f471c9621daeed44fcc的间隙锁;而为了防止在分裂维护过程中重新插入数据,可能不得不为相关页记录的 supremum 加上间隙锁,以维护页分裂的执行过程

    这个过程可能如下:

    插入记录前:

    split_2.png

    插入记录导致页分裂后

    split_4.png

    注意: 这里关于分页而产生的间隙锁为实际实验推断,并无实际文档与之关联。当事务隔离级别为 "读提交" 或插入的记录的主键存在顺序时,都不会出现上文描述的死锁出现

解决方案

实际上,如果事务执行速度特别快,并且在并发量不高的情况下,这种类型的死锁很难被检测到,因为需要处理的事务跨多个页,并且需要关联到两个不同页的锁本身就很难。因此,将逐行的 INSERT 语句替换为批量提交后也可以很大程度上解决这一问题

为了尽可能地避免这一类问题,推荐的一些方案如下:

  • 如果没有特殊必要,可以使用隔离级别较低的事务隔离级别,因为这样可以减少实际事务处理过程中锁的数量,降低锁冲突的可能性
  • 尽量使用有序的主键,不管是从性能上还是实际业务角度,都没有理由选择 UUID 的理由
  • 如果可以,适当减少事务的粒度,如:将一个大事务分成几个小事务,在性能和一致性上做一定的权衡

参考:

[1] https://mp.weixin.qq.com/s/9LRFYGquXWpMCeyAonNcMQ

[2] https://dev.mysql.com/doc/refman/8.0/en/innodb-locks-set.html

http://www.sczhlp.com/news/44289/

相关文章:

  • 【LeetCode 437】算法:路径总和 III
  • n8n获取每日资讯 Gnewsapi 调用
  • 成都网站建设哪家好文章网站快速排名互点软件
  • 网站建设在作用是什么原因黑帽seo论坛
  • 江门做网站软件中央人民政府
  • 重庆奉节网站建设百度一下首页网页手机版
  • java网站建设兼职朔州seo
  • hadoop hdfs 命令大全
  • 做外贸网站要花多少钱广东疫情动态人民日报
  • 什么网站可以做任务赚钱许昌网站seo
  • 做网站怎么做连接点下一个页面国际军事最新消息今天
  • 优秀手机网站徐州seo推广
  • 济南专业网站托管公司网络营销公司招聘
  • 什么网站类型天津seo博客
  • wordpress花园教程陕西seo排名
  • 网站开启微信支付功能新手如何学seo
  • AST与虚拟 DOM(VNode)
  • [hdu6566]The Hanged Man
  • 微信小程序二次开发谷歌seo网站建设
  • 湖北省建设工程网站网络软文推广案例
  • wordpress emlog zblog如何做seo搜索引擎优化
  • 青原区城乡建设局门户网站免费网站java源码大全
  • 怎么做刷qq会员的网站百度快速收录开通
  • 石嘴山网站关于两学一做信息流广告哪个平台好
  • 腾讯云服务器用什么软件做网站中国站长站
  • 上海做网站比较好的宁德市教育局官网
  • 开发大型网站写一篇软文1000字
  • 网站建设教程视频西瓜香港seo公司
  • 使用 Prometheus 进行黑盒监控( Blackbox Exporter 的安装和配置)
  • saas系统是什么意思啊微信seo什么意思