实际业务场景

在我们使用mysql的时候,如果不注意间隙锁容易引起死锁,最近分析一个业务场景就是间隙锁导致的死锁,业务抽象如下:

系统有一个批量新增业务资源的功能,实现逻辑如下(businnessid为非唯一索引):

update 业务表 set isdeleted=1 where bussinessid=123;

insert into 业务表

在并发场景下,以上逻辑产生了死锁。

以下为死锁具体分析以及还原死锁产生过程,最后给出解决方案。

创建一张表

CREATE TABLE `lock_demo` (

`id` INT NOT NULL AUTO_INCREMENT,

`index` INT NOT NULL,

`name` VARCHAR(50) NULL DEFAULT NULL,

PRIMARY KEY (`id`),

INDEX `index` (`index`)

)

COLLATE=’utf8mb4_0900_ai_ci’

ENGINE=InnoDB

;

死锁演示

事务一

事务二

update lock_demo set name=’a’ where index=1;

update lock_demo set name=’a’ where index=2;未卡住,间隙锁之间不冲突

insert into lock_demo(id,`index`,name)values(1,1,’1′);

卡住,被事务二的间隙锁锁住

insert into lock_demo(id,`index`,name)values(2,2,’2‘);

检测到死锁

具体步骤步骤一

事务一

先更新一条记录(不存在),不提交。

步骤二

事务二

更新一条记录(不存在),不提交。

步骤三

事务一,执行一条新增语句,被事务二的间隙锁锁住

步骤四

事务二,执行一条新增语句,被事务一的间隙锁锁住,系统检测到死锁

解决方案

对于以上的业务,可以改写sql避免死锁

select id from 业务表where bussinessid=123;

如果存在,

update 业务表 set isdeleted=1 where id in (xxx);

insert into 业务表