将共享升级到独占锁时避免MySQL死锁

Question

我正在使用MySQL 5.5.我注意到在并发场景中发生了一个特殊的死锁,我不认为应该发生这种死锁.

使用两个同时运行的mysql客户端会话重现:

mysql会话1:

create table parent (id int(11) primary key);
insert into parent values (1);
create table child (id int(11) primary key, parent_id int(11), foreign key (parent_id) references parent(id));

begin;
insert into child (id, parent_id) values (10, 1);
-- this will create shared lock on parent(1)

mysql session 2:

begin;
-- try and get exclusive lock on parent row
select id from parent where id = 1 for update;
-- this will block because of shared lock in session 1

mysql会话1:

-- try and get exclusive lock on parent row
select id from parent where id = 1 for update;
-- observe that mysql session 2 transaction has been rolled back

mysql session 2:

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

报告的信息show engine innodb status是:

------------------------
LATEST DETECTED DEADLOCK
------------------------
161207 10:48:56
*** (1) TRANSACTION:
TRANSACTION 107E67, ACTIVE 43 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 13074, OS thread handle 0x7f68eccfe700, query id 5530424 localhost root statistics
select id from parent where id = 1 for update
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 3714 n bits 72 index `PRIMARY` of table `foo`.`parent` trx id 107E67 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 000000107e65; asc     ~e;;
 2: len 7; hex 86000001320110; asc     2  ;;

*** (2) TRANSACTION:
TRANSACTION 107E66, ACTIVE 52 sec starting index read
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 12411, OS thread handle 0x7f68ecfac700, query id 5530425 localhost root statistics
select id from parent where id = 1 for update
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 3714 n bits 72 index `PRIMARY` of table `foo`.`parent` trx id 107E66 lock mode S locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 000000107e65; asc     ~e;;
 2: len 7; hex 86000001320110; asc     2  ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 3714 n bits 72 index `PRIMARY` of table `foo`.`parent` trx id 107E66 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 000000107e65; asc     ~e;;
 2: len 7; hex 86000001320110; asc     2  ;;

*** WE ROLL BACK TRANSACTION (1)

您可以看到事务(1)未显示已获取的任何S或X锁; 它只是被阻止试图获得一个独家锁.由于没有循环,在这种情况下不应该出现死锁,正如我所理解的那样.

这是一个已知的MySQL错误吗？还有其他人遇到过吗？使用了哪些变通方法？

这些是我们可以采取的可能步骤:

• 减少我们对外键的使用(在我们的生产场景中,我们只在引用的表中软删除行,但是很蹩脚)
• 获取前面的独占锁而不是隐式共享锁(将减少我们的并发吞吐量)
• 更改我们的逻辑,以便我们不再需要在同一事务中添加父行的独占锁定(冒险和硬)
• 将我们的MySQL版本更改为不会出现此行为的版本

我们还没有考虑其他选择吗？

Answer 1

这是一个长期存在的错误,您可以从以下内容中了解更多:此错误报告

这是MySQL级表锁定中的一个问题.

在InnoDB内部,FOREIGN KEY约束检查可以读取(或使用ON UPDATE或ON DELETE子句,写入)父表或子表.

通常,表访问由以下锁控制:1.MySQL元数据锁2. InnoDB表锁3. InnoDB记录锁

所有这些锁都保持到事务结束.

在某些模式下会跳过InnoDB表和记录锁,但在外键检查期间不会跳过.导致死锁是因为MySQL仅为SQL语句中明确提到的表获取元数据锁.

我想一个解决方法可能是在有问题的FOREIGN KEY操作之前,在事务开始时访问子(或父)表.

阅读讨论和它的回复