insert事务产生duplicate key error引发的死锁分析

先看程序报错：

从报错信息可以看出有死锁，insert SQL导致，研发有些不理解，insert操作怎么会导致死锁？

我们都知道， insert into values存在X row record lock。

但后面的需要更加注意，对于存在auto_increment列，存在X lock在auto_increment列的index，特殊的表级AUTO-INC lock，如果insert产生duplicate-key错误，则在duplicate index record设置S lock，如果多个session插入同一行则可以产生deadlock。

官方文档对于insert 加锁说明：

Insert sets an exclusive lock on the inserted row. This lock is an index-record lock, not a next-key lock (that is, there is no gap lock) and does not prevent other sessions from inserting into the gap before the inserted row.Prior to inserting the row, a type of gap lock called an insertion intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.If a duplicate-key error occurs, a shared lock on the duplicate index record is set. This use of a shared lock can result in deadlock should there be multiple sessions trying to insert the same row if another session already has an exclusive lock.

大概意思就是：insert会对插入成功的行加上排它锁，这个排它锁是个记录锁，而非next-key锁（也不是gap锁了），不会阻止其他并发的事务往这条记录之前插入记录。在插入之前，会先在插入记录所在的间隙加上一个插入意向gap锁，并发的事务可以对同一个gap加意向gap锁。如果insert 的事务出现了duplicate-key error ，事务会对duplicate index record加共享锁。这个共享锁在并发的情况下是会产生死锁的，比如有两个并发的insert都对要对同一条记录加共享锁，而此时这条记录又被其他事务加上了排它锁，排它锁的事务提交或者回滚后，两个并发的insert操作是会发生死锁。

先看下加锁的表结构，存在id主键和sku_id,prop_type,com_att_id,source的唯一索引：

CREATE TABLE `sku_1` (
      `id` bigint(20) NOT NULL  AUTO_INCREMENT COMMENT '自增',
      `sku_id` bigint(20) NOT NULL,
      `prop_type` tinyint(4) DEFAULT  NULL,
      `com_att_id` int(11) DEFAULT  NULL,
      `com_att_val_id` varchar(150)  DEFAULT NULL,
      `val` varchar(200) DEFAULT  NULL,
      `source` int(11) DEFAULT  NULL,
      `category_id` int(11) DEFAULT  NULL,
      `version` varchar(50) DEFAULT  NULL,
      `created` datetime DEFAULT  NULL,
      `modified` datetime DEFAULT  NULL,
      PRIMARY KEY (`id`),
      UNIQUE KEY `unique`  (`sku_id`,`prop_type`,`com_att_id`,`source`)
    ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;

演示下insert 的事务出现了duplicate key error的情况：

通过innodb_locks、innodb_lock_waits查看当前索引信息：

4475是事务1 ，4480和4481分别是事务2和3，从innodb_locks表中可以看出事务1是X记录锁，事务2和3是S记录锁，且这三个锁对应的是同样的记录，从innodb_lock_waits表可以看出事务2和事务3的S锁被事务1的X锁阻塞了。

当事务1 rollback后，事务2和事务3发生死锁。

通过show engine innodb status查看死锁日志如下：

从上面死锁日志，我们可以很容易理解死锁为何发生。事务1插入记录，事务2插入同一条记录，主键冲突，事务2将事务1的隐式锁转为显式锁，同时事务2向队列中加入一个s锁请求;

事务3同样也加入一个s锁请求；

当事务1回滚后，事务2和事务3获得s锁，但随后事务2和事务3又先后请求插入意向锁，因此锁队列为：

事务2(S GAP)<—事务3(S GAP)<—事务2(插入意向锁)<–事务3(插入意向锁)

事务3（S锁）,事务2（X锁）,事务3（X锁）形成死锁。这样的死锁不光出现在unique key，还包括primary key。

优化insert引起的死锁：

1、从程序逻辑上处理，尽量不要在高并发下同时insert一条数据

2、如果非特殊需求修改为非唯一索引

3、通过数据库连接池做分发处理

4、并发插入时，不在一个事务内进行再次事务提交 5、通过其他手段，如缓存方案，解决这个要并发插入的问题

6、改并发为串行执行