MySQL 并发插入导致死锁

作者：云舒编程

2024-01-25
广东
本文字数：2935 字
阅读完需：约 10 分钟

大家好，我是「云舒编程」，今天我们来聊聊 MySQL 并发插入导致死锁。

文章首发于微信公众号：云舒编程
关注公众号获取：1、大厂项目分享 2、各种技术原理分享 3、部门内推

背景

某天下午组里有一个对外提供创建租户的接口突然产生了 MySQL 死锁的报警。

该服务是一个老服务，至少有一年没有人改动过该接口，并且租户这个场景只支持创建和查询，其他能力都不支持。收到报警的一刻，内心充满了疑惑："这也能死锁?"

死锁日志

先是到 MySQL 上获取了死锁日志：

关于插入意向锁，MySQL 官网有如下解释说明：

结合死锁日志和官网说明大概推断死锁原因是：

事务一持有了某个记录的 S 型 Next_LOCK 锁(也就是 S 锁+GAP 锁)，然后等待另一个 S 型 Next_LOCK 锁。
事务二持有了某个记录的 X 锁，同时想获取某个间隙的插入意向锁。

也就是形成了下图的环：

其实到这还是无法根据死锁日志信息看出来为什么会形成环。不过由于表中的 tenant_id 是由调用方指定传入的，所以可以根据 tenant_id 去搜索日志，找到对应的 trace_id，追踪当时整个链路发生了什么。

链路分析

不搜不要紧，一搜吓一跳。根据 tenant_id 搜索发现从网关发起了两条一模一样的请求，发起的时间也是一模一样。也就是说在 MySQL 层产生了并发插入。

同时发现插入数据的代码居然是使用的 for 循环插入，而不是批量插入。

for _, tenant := range tenants {    if err := model.GetDB().Model(&model.Goods{}).Create(tenant).Error; err != nil {      return nil, err    }  }

复制代码

同时在 MySQL 官网找到一段关于并发插入可能导致死锁的说明：

按照图中的说法，当插入一条数据时会先给该数据加上排他锁，如果发生了「duplicate-key error」，那么就会加上共享锁，这样就会导致当出现多个会话同时插入数据并且发生「duplicate-key error」时就会导致死锁。

同时文中给了一个死锁案例：

刚好我们的 t_tenant 表中的 tenant_id 是唯一索引。不过官网的案例跟我获取的死锁信息和请求链路信息有所不同，

官网的死锁必须要 3 个或者 3 个以上的并发才会导致死锁，但是我的并发只有两个，按照图中的举例产生不了死锁的条件。
官网举例中只会产生排他锁和共享锁，但是死锁日志中出现了 S 型 Next_lock 锁。

不过由于没有新的突破点，打算先按照并发插入导致死锁的思路尝试进行复现，如果可以稳定复现，那应该就是并发加上唯一索引重复冲突导致的了。

也就是说当时的场景应该如下：

按照这个时序执行逻辑和官网的加锁说明：

事务一先对(1,"test1")加上 X 锁(即排他锁，但是这里没有加 GAP 锁)
事务二插入(1,"test1")，由于 tenant_id 是唯一索引，导致「duplicate-key error」，那么事务二在(1,"test1")加上 S 锁(即共享锁，同样这里没有 GAP 锁）
然后事务一插入(2,"test2")，同时给(2,"test2")加上 X 锁(即排他锁，但是这里没有加 GAP 锁)

分析到这里，不对啊，这里没有产生环啊，不可能产生死锁啊

就在产生疑惑的时候，线上又出了一例死锁，查看死锁日志和请求日志。发现跟之前的一模一样，依旧是网关发起两条一模一样的请求，依旧是批量插入租户数据。

到这里只能死马当做活马医，先在本地用上面的请求时序模拟复现一遍，先不管理论原因了。

模拟复现

MySQL 版本：8.0
隔离级别：REPEATABLE-READ

CREATE TABLE `t_tenant` (  `id` int unsigned NOT NULL AUTO_INCREMENT,  `tenant_id` int DEFAULT NULL,  `name` varchar(255) DEFAULT NULL,  PRIMARY KEY (`id`),  UNIQUE KEY `uk_tenant_id` (`tenant_id`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

复制代码