死锁案例八

文 | 杨一 on 运维

转 | 来源：公众号yangyidba

一、前言

死锁其实是一个很有意思也很有挑战的技术问题，大概每个 DBA 和部分开发朋友都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。

二、案例分析

2.1 业务场景

业务上的主要逻辑:

首先执行插入数据，如果插入成功，则提交。如果插入的时候报唯一键冲突，则执行更新。 如果同时出现三个并发在执行数据初始化动作，sess1 插入成功，sess2 和 sess3 插入遇到唯一键冲突，插入失败，则都执行执行更新，于是出现死锁。

2.2 环境准备

MySQL 5.6.24 事务隔离级别为 RR

1. create table ty (

2. id int not null primary key auto_increment ,

3. c1 int not null default 0,

4. c2 int not null default 0,

5. c3 int not null default 0,

6. unique key uc1(c1),

7. unique key uc2(c2)

8. ) engine=innodb ;

9. insert into ty(c1,c2,c3) values(1,3,4),(6,6,10),(9,9,14);

2.3 测试用例

为了方便分析死锁日志，三个会话插入的 c3 的值分别为1 2 3 ，生产上其实是相同的值。

2.4 死锁日志

1. 2018-03-28 10:04:52 0x7f75bf2d9700

2. *** (1) TRANSACTION:

3. TRANSACTION 1870, ACTIVE 76 sec starting index read

4. mysql tables in use 1, locked 1

5. LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)

6. MySQL thread id 399265, OS thread handle 12, query id 9 localhost root updating

7. update ty set c3=5 where c1=4

8. *** (1) WAITING FOR THIS LOCK TO BE GRANTED:

9. RECORD LOCKS space id 28 page no 4 n bits 72 index uc1 of table `test`.`ty` trx id 1870 lock_mode X locks rec but not gap waiting

10. *** (2) TRANSACTION:

11. TRANSACTION 1871, ACTIVE 32 sec starting index read, thread declared inside InnoDB 5000

12. mysql tables in use 1, locked 1

13. 3 lock struct(s), heap size 1136, 2 row lock(s)

14. MySQL thread id 399937, OS thread handle 16, query id 3 localhost root updating

15. update ty set c3=5 where c1=4

16. *** (2) HOLDS THE LOCK(S):

17. RECORD LOCKS space id 28 page no 4 n bits 72 index uc1 of table `test`.`ty` trx id 1871 lock mode S

18. *** (2) WAITING FOR THIS LOCK TO BE GRANTED:

19. RECORD LOCKS space id 28 page no 4 n bits 72 index uc1 of table `test`.`ty` trx id 1871 lock_mode X locks rec but not gap waiting

20. *** WE ROLL BACK TRANSACTION (2)

其实单单从日志上查看只看到两个事务的 update 相互竞争，在缺乏业务逻辑场景的情况下，很难得到有效思路。

2.5 分析死锁日志

T2 s1 执行 insert 操作，检查唯一性且插入成功,持有 c1=4 记录行的行锁。

T3 s2 insert遇到唯一键冲突，申请加锁 Lock S Next-key Lock 日志显示为 index uc1 of table test.ty trx id 1870 lock mode S waiting

T4 与 s2 相同, s3 insert 遇到唯一键冲突，申请加锁 Lock S Next-key Lock 日志显示为 index uc1 of table test.ty trx id 1870 lock mode S waiting

T5 sess1 执行 commit 操作, 此时 sess2 和 sess3 同时获取 Lock S Next-key Lock。

T6 应用收到唯一键冲突，sess2 执行 update 操作需要申请 c=4 的行锁，与 sess3的持有的 Lock S Next-key Lock 不兼容，等待 sess3 释放Lock S Next-key Lock。

T7 与sess2 类似 sess3 执行update 操作需要申请 c=4 的行锁，与 sess2 的持有的 Lock S Next-key Lock 不兼容，等待 sess2 释放 Lock S Next-key Lock 。出现循环等待，发生死锁。

2.6 解决方法

本案例的解决方式其实和前文 死锁案例之七 一致，使用 insert on duplicate key。案例七与本案例导致死锁业务逻辑极为相似，为什么呢？因为都是同一组开发哥哥写的。

三、小结

导致死锁的根本原因是不同事务申请锁的顺序不一样出现循环等待，开发同学在设计高并发的业务场景时，需要着重思考这一点，并且尽量规避业务场景设计不合理导致死锁。

另外就是 insert 的加锁机制相对 update 其实比较复杂，需要多动手实践，理清加锁流程。

扩展阅读

-The End-

Vol.163

有赞技术团队

为 300 万商家，150 个行业，200 亿电商交易额

提供技术支持

微商城｜零售｜美业

微信公众号：有赞coder    微博：@有赞技术

技术博客：tech.youzan.com

The bigger the dream, 

the more important the team.