文章首发于微信公众号：云舒编程

关注公众号获取： 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循环插入，而不是批量插入。

golang 复制代码

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锁。

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

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

时刻	事务一	事务二
T1	begin;	begin;
T2	insert into t_tenant(tenant_id,name) values(1,"test1");
T3		insert into t_tenant(tenant_id,name) values(1,"test1");
	insert into t_tenant(tenant_id,name) values(2,"test2");

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

事务一先对(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

sql 复制代码

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

时刻	事务一	事务二
T1	begin;	begin;
T2	insert into t_tenant(tenant_id,name) values(1,"test1");
T3		insert into t_tenant(tenant_id,name) values(1,"test1");
	insert into t_tenant(tenant_id,name) values(2,"test2");

拿着上面的请求时序进行模拟，发现根本不会产生死锁。

事务二在事务一提交之前全程都是被阻塞的，当事务一提交之后，事务二就直接报唯一键冲突了，根本不会产生死锁。

柳暗花明又一村

到这里彻底失去了眉目，连复现都复现不了更别说分析原因了。就当我想先放下后面再处理时，又来了一例死锁，同时leader也过来问解决进度，没办法只能继续分析了。

拿着三个死锁日志发现完全看不出来什么，于是重新分享请求日志，这一分析就发现了华点。三个死锁的请求都来自同一个调用方，同时他们传递过来的数组中的tenant_id是降序的。

难道是这个原因？也太逆天了吧，抱着试一试的心态，重新修改了执行逻辑：

时刻	事务一	事务二
T1	begin;	begin;
T2	insert into t_tenant(tenant_id,name) values(2,"test2");
T3		insert into t_tenant(tenant_id,name) values(2,"test2");
	insert into t_tenant(tenant_id,name) values(1,"test1");