mysql排他锁 升级_将共享升级到排他锁时避免MySQL死锁

我使用MySQL 5.5。我注意到在并发情况下发生了特殊的僵局，我不认为这种僵局应该发生。

重现这样，使用两个同时运行的mysql客户端会话：

mysql session 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 session 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会话2：

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

从显示引擎innodb状态报告的信息是：

------------------------

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 bug吗？有其他人遇到过吗？使用了哪些解决方法？

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

>减少我们对外键的使用(在我们的生产场景中，我们只是软删除引用的表中的行，但是是icky)

>获取排他锁，而不是隐式共享锁(将减少我们的并发吞吐量)

>改变我们的逻辑，所以我们不再需要在添加子行的同一个事务中对父进行排他锁(有风险和难度)

>将我们的MySQL版本更改为不显示此行为的版本

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