mysql中删除同一行会经常出现死锁？太可怕了

 

1. 是不是在一个事务中做了好几件事情?

     答：不是，只做一个删除操作，自动提交

2. 有多少个线程在做删除？

     答：差不多10个

3. 是什么隔离级别？

     答：可重复读

 

当时觉得不可思议，按说自动提交的话行锁，如果已经有事务加锁了，则会等待，等提交之后再去做，发现已经删除了，就会返回，删除0条，为什么会死锁？

但事情已经出了，必须研究一下，不然终究是心头之苦啊。

然后想到既然线上有这么简单的操作就可以死锁，那么应该写个简单的程序就可以重现，然后同事李润杰兄弟咔嚓咔嚓没多时就给我了，在这里谢谢他。

 

首先环境是这样的：

CREATE TABLE `abcdefg` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `abc` varchar(30),
  `def` varchar(30) ,
  `ghi` date,
  `jkl` date,
  `mnp` tinyint(4),
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniqdefghijkl` (`def`,`ghi`,`jkl`)
);

 

这个表包括2个索引，一个是聚簇索引，另一个是uniqdefghijkl的二级唯一索引。

事先插入很多数据，然后3个线程同时做对同一条记录的删除，这里只做删除操作，并且都是自动提交，为了得到一批要删除的数据，事先查询很多条出来备用。

 

删除语句是这样的：

delete from abcdefg WHERE abc= '我是变量' and def= '我是变量' and ghi= '2013-12-19 00:00:00' and jkl= '2013-12-20 00:00:00';

那么现在就开始重现。。。

果然很快，死锁真的出现了，下面是执行show engine innodb status的结果：

===================================================

LATEST DETECTED DEADLOCK
------------------------
140123 12:20:50
*** (1) TRANSACTION:
TRANSACTION 2E10, ACTIVE 4917 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 3, OS thread handle 0x1008, query id 43 192.168.xx.x username upd
ating
delete from abcdefg WHERE abc= '我是变量' and def= '我是变量' and ghi= '2013-12-19 00:00:00' and jkl= '2013-12-20 00:00:00';

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 12295 n bits 528 index `uniqdefghijkl` of table

`deadlock`.`abcdefg` trx id 2E10 lock_mode X locks rec but not gap waiti

ng
Record lock, heap no 167 PHYSICAL RECORD: n_fields 4; compact format; 

*** (2) TRANSACTION:
TRANSACTION 2E0E, ACTIVE 4917 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1248, 2 row lock(s)
MySQL thread id 1, OS thread handle 0x1190, query id 41 192.168.xx.xx username upd

ating
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 12295 n bits 528 index `uniqdefghijkl` of table

`deadlock`.`abcdefg` trx id 2E0E lock_mode X locks rec but not gap

Record lock, heap no 167 PHYSICAL RECORD: n_fields 4; compact format; 

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 12295 n bits 528 index `uniqdefghijkl` of table

`deadlock`.`abcdefg` trx id 2E0E lock_mode X waiting

Record lock, heap no 167 PHYSICAL RECORD: n_fields 4; compact format; 
*** WE ROLL BACK TRANSACTION (1)

===================================================

这是在三个线程的情况下是可以重现死锁的，但是为了更容易调试，试了一下在2个线程的情况下如何，最终发现重现不了。

这下坏了，多线程调试很麻烦，有时候这个走那个不走的，如果冻结某个线程，有可能导致线程之间死锁，或者自然执行，那又不能出现死锁的情况，因为这个死锁也是偶然性的，所以最终只有一种方法，那就是在mysql代码中打印log信息，将锁、记录与事务这块的函数中具有分歧点的地方都加了注释，并且将有用的信息打印出来，最终分析log文件，才发现了真正死锁的猫腻。

 

现在将三个导致死锁的事务的时序图画出来：