MySQL死锁套路之唯一索引下批量插入顺序不一致

前言

死锁的本质是资源竞争，批量插入如果顺序不一致很容易导致死锁，我们来分析一下这个情况。为了方便演示，把批量插入改写为了多条 insert。

先来做几个小实验，简化的表结构如下

create table `t1` (
 `id` int(11) not null auto_increment,
 `a` varchar(5),
 `b` varchar(5),
 primary key (`id`),
 unique key `uk_name` (`a`,`b`)
);

实验1：

在记录不存在的情况下，两个同样顺序的批量 insert 同时执行，第二个会进行锁等待状态

t1	t2
begin;	begin;
insert ignore into t1(a, b)values("1", "1");		成功
	insert ignore into t1(a, b)values("1", "1");	锁等待状态

可以看到目前锁的状态

mysql> select * from information_schema.innodb_locks;
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+
| lock_id  | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+
| 31ae:54:4:2 | 31ae  | s   | record | `d1`.`t1` | `uk_name` |   54 |   4 |  2 | '1', '1' |
| 31ad:54:4:2 | 31ad  | x   | record | `d1`.`t1` | `uk_name` |   54 |   4 |  2 | '1', '1' |
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+

在我们执行事务t1的 insert 时，没有在任何锁的断点处出现，这跟 mysql 插入的原理有关系

insert 加的是隐式锁。什么是隐式锁？隐式锁的意思就是没有锁

在 t1 插入记录时，是不加锁的。这个时候事务 t1 还未提交的情况下，事务 t2 尝试插入的时候，发现有这条记录，t2 尝试获取 s 锁，会判定记录上的事务 id 是否活跃，如果活跃的话，说明事务未结束，会帮 t1 把它的隐式锁提升为显式锁（ x 锁）

源码如下

t2 获取s锁的结果:db_lock_wait

实验2：

批量插入顺序不一致的导致的死锁

t1	t2
begin
insert into t1(a, b)values("1", "1");		成功
	insert into t1(a, b)values("2", "2");	成功
insert into t1(a, b)values("2", "2");		t1 尝试获取 s 锁，把 t2 的隐式锁提升为显式 x 锁，进入 db_lock_wait
	insert into t1(a, b)values("1", "1");	t2 尝试获取 s 锁，把 t1 的隐式锁提升为显式 x 锁，产生死锁

------------------------
latest detected deadlock
------------------------
181101 9:48:36
*** (1) transaction:
transaction 3309, active 215 sec inserting
mysql tables in use 1, locked 1
lock wait 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 2
mysql thread id 2, os thread handle 0x70000a845000, query id 58 localhost root update
insert into t1(a, b)values("2", "2")
*** (1) waiting for this lock to be granted:
record locks space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 3309 lock mode s waiting
record lock, heap no 3 physical record: n_fields 3; compact format; info bits 0
 0: len 1; hex 32; asc 2;;
 1: len 1; hex 32; asc 2;;
 2: len 4; hex 80000002; asc  ;;

*** (2) transaction:
transaction 330a, active 163 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 2
mysql thread id 3, os thread handle 0x70000a888000, query id 59 localhost root update
insert into t1(a, b)values("1", "1")
*** (2) holds the lock(s):
record locks space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 330a lock_mode x locks rec but not gap
record lock, heap no 3 physical record: n_fields 3; compact format; info bits 0
 0: len 1; hex 32; asc 2;;
 1: len 1; hex 32; asc 2;;
 2: len 4; hex 80000002; asc  ;;

*** (2) waiting for this lock to be granted:
record locks space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 330a lock mode s waiting
record lock, heap no 2 physical record: n_fields 3; compact format; info bits 0
 0: len 1; hex 31; asc 1;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc  ;;

*** we roll back transaction (2)

怎么样解决这样的问题呢？

一个可行的办法是在应用层排序以后再插入

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。