死锁案例之十

一 前言

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

二 案例分析

2.1 业务场景

业务开发同学要做业务逻辑迁移，由A表迁移到B表,B表承担所有的类型的业务，他们的业务逻辑是:上游发task_id列表给下游，下游的业务根据一定的逻辑进行处理，在并发更新时遇到死锁。

注意: 因为B是新表，不一定有对应task_id的值。

2.2 环境说明

MySQL 5.6.24 事务隔离级别为RR

create table  x
(id int not null auto_increment,
 c int not null default  0,
 d int not null default 0,
 primary key(id),
 key idxcd(c,d));
insert into x(c,d) values(1,0),(3,0),(5,0),
(7,0),(10,0),(12,0),(14,0),(16,0);

2.3 测试用例

2.4 死锁日志

2018-04-20 23:05:55 0x7f75cdfff700 *** (1) TRANSACTION: TRANSACTION 2235, ACTIVE 161 sec updating or deleting mysql tables in use 1, locked 1 LOCK WAIT 5 lock struct(s), heap size 1136, 8 row lock(s), undo log entries 1 MySQL thread id 1016626, OS thread handle 140143880890112, query id 4070003 127.0.0.1 root updating update x set d=1 where c in (5,10) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 44 page no 4 n bits 80 index idxcd of table `test`.`x` trx id 2235 lock_mode X locks gap before rec insert intention waiting *** (2) TRANSACTION: TRANSACTION 2237, ACTIVE 36 sec updating or deleting, thread declared inside InnoDB 4997 mysql tables in use 1, locked 1 5 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 1 MySQL thread id 1016629, OS thread handle 140143944005376, query id 4070021 127.0.0.1 root updating update x set d=1 where c=7 *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 44 page no 4 n bits 80 index idxcd of table `test`.`x` trx id 2237 lock_mode X locks gap before rec *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 44 page no 4 n bits 80 index idxcd of table `test`.`x` trx id 2237 lock_mode X locks gap before rec insert intention waiting *** WE ROLL BACK TRANSACTION (2)

2.5 分析死锁日志

首先我们要再次强调insert 插入操作的加锁逻辑。

第一阶段: 唯一性约束检查，先申请LOCK_INSERT_INTENTION

第二阶段: 如果没有唯一键冲突，新数据插入完成之后:LOCK_X + LOCK_REC_NOT_GAP

对于insert操作来说，若发生唯一约束冲突，需要对冲突的唯一索引申请加上S Next-key Lock。如果其他会话中包含已经插入记录的事务没有提交，则申请加锁出现等待，show engine innodb status中的事务列表中会提示 lock mode S waiting 。

从这里会发现，即使是RC事务隔离级别，也同样会存在Next-Key Lock锁，从而阻塞并发。然而，文档没有说明的是，对于检测到冲突的唯一索引，等待线程在获得S Lock之后，还需要对下一个记录进行加锁，在源码中由函数row_ins_scan_sec_index_for_duplicate进行判断.

其次 我们需要了解锁的兼容性矩阵。

从兼容性矩阵我们可以得到如下结论:

INSERT操作之间不会有冲突。

GAP,Next-Key会阻塞插入意向锁INSERT_INTENTION

GAP与Record,Next-Key不会冲突

Record与Record、Next-Key之间相互冲突。

已有的Insert锁不阻止任何准备加的锁。

另外 RR事务隔离级别下,对于通过索引(唯一或者非唯一)更新或者删除不存在的记录，会申请加上gap锁。

当update 更新被索引字段时，相当于删除之后重新插入新的记录，需要重新组织索引节点。

了解上面的基础知识，我们开始对死锁日志进行分析:

T1时刻 开始事务。

T2时刻 sess2 更新c=6的值，但是c=6 不存在，申请加上(5,0)---(7,0)的X gap锁，日志提示:持有idxcd of table test.x trx id 2207 lock_mode X。

T3时刻 sess1 更新2行记录c=5,c=10,并且修改d=1,ses1 会申请(5,0),(10,0) 记录之间的Next-key锁,由于sess1需要插入新的记录(5,1)sess2 持有的X GAP 锁范围内,根据锁的兼容性矩阵，GAP,Next-Key会阻塞插入意向锁INSERT_INTENTION，故日志提示:index idxcd of table test.x trx id 2235 lock_mode X locks gap before rec insert intention waiting 。

T4时刻 sess2 更新c=7对应d=1,同样相当于insert (7,1) 在(5,0),(10,0)之间。根据兼容矩阵GAP,Next-Key会阻塞插入意向锁INSERT_INTENTION 故日志提示: index idxcd of table test.x trx id 2237 lock_mode X locks gap before rec insert intention waiting 。

至此,sess2 持有gap锁阻塞sess1 插入(5,1)，sess1持有Next-key 阻塞sess2 插入(7,1),循环等待出现死锁。

2.6 解决方法

其实解决方法比较简单 把组合索引 idxcd(c,d) 中的d去掉，改为idxc(c),避免GAP/Next-key 阻塞插入意向锁INSERT_INTENTION 即可，开发同学18:10分左右修改索引之后，业务不再出现死锁。

三 小结

本文的死锁算是蛮有意思的一个案例:并发多个update更新二级索引列，相当于索引节点重新组织,更新等于删除加插入，在死锁日志出现了插入意向锁。第一次猜想的时候还以为有 多个insert 操作，但是实际上只有更新动作。

最后想说关于解决死锁问题的思路:

1. 具备扎实的锁相关的基础知识。

2. 单单根据死锁日志其实比较难以判断具体的sql执行情况，需要和开发同学沟通好(当然开发也要提提供完整的业务逻辑)，理清业务执行sql的逻辑，然后去模拟测试。