关于 MySQL 中的 InnoDB 死锁的问题？

Question

我在 MySQL InnoDB 引擎中发现了这种有趣的问题，谁能解释为什么引擎总是声称它是死锁。

首先，我创建了一个单行单列的表：

   CREATE TABLE `SeqNum` (`current_seq_num` bigint(30) NOT NULL default '0',
                           PRIMARY KEY  (`current_seq_num`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;
   Query OK, 0 rows affected (0.03 sec)

   mysql> insert into SeqNum values (5);
   Query OK, 1 row affected (0.00 sec)

现在，我有两个 MySQL 连接器线程，在 thread1：

    mysql> begin;
    Query OK, 0 rows affected (0.00 sec)

    mysql> select `current_seq_num` into @curr_seq FROM SeqNum FOR UPDATE;
    Query OK, 1 row affected (0.00 sec)

现在，在 thread2 中，我做了完全相同的事情：

    mysql> begin;
    Query OK, 0 rows affected (0.00 sec)

    mysql> select `current_seq_num` into @curr_seq FROM SeqNum FOR UPDATE;

在默认的innodb_lock_wait_timeout之前，thread2只是等待thread1释放对表的排他锁，这是正常的。

但是，在thread1中，如果我输入以下更新查询：

     mysql> update SeqNum set `current_seq_num` = 8;
     ERROR 1213 (40001): Deadlock found when trying to get lock; 
     try restarting transaction

现在，thread2 完成了 select 查询，因为 thread1 退出了。

另外，在thread1中，如果我输入带有where子句的更新查询，可以很好的执行：

     mysql> update SeqNum set `current_seq_num` = 8 where `current_seq_num` =5
     Query OK, 1 row affected (0.00 sec)

谁能解释一下？

Answer 1

为什么你甚至想要执行这条 SQL 而不是

REPLACE INTO SeqNum VALUES (NULL); 
SELECT last_insert_id();

Answer 2

“SELECT ... FOR UPDATE”在 SeqNum 表上放置一个 INTENTION EXCLUSIVE (IX) 锁，并在所有符合 SELECT 条件的行上放置一个 EXCLUSIVE (X) 锁。

可以使用 Innodb 锁监视器查看锁的状态。这是通过创建一个特殊命名的表来实现的：

create table innodb_lock_monitor( i int not null ) engine = innodb;

只要发出以下命令，就会显示锁的状态：

show engine innodb status \G

当第一个线程执行“Select ... for update”时，会放置以下锁（我在表中有一行值为5）：

MySQL thread id 42, query id 338 localhost root
TABLE LOCK table `test`.`SeqNum` trx id 0 1284 lock mode IX
RECORD LOCKS space id 0 page no 51 n bits 72 index `PRIMARY` of table `test`.`SeqNum` trx id 0 1284 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 8; hex 8000000000000005; asc         ;; 1: len 6; hex 000000000503; asc       ;; 2: len 7; hex 800000002d0110; asc     -  ;;

这是表上的 IX 锁和两个 X 锁 - 一个在唯一行之后的间隙（上）上，另一个在实际数据行上。

在第二个线程执行“select ... for update”时，会添加以下锁：

TABLE LOCK table `test`.`SeqNum` trx id 0 1285 lock mode IX
RECORD LOCKS space id 0 page no 51 n bits 72 index `PRIMARY` of table `test`.`SeqNum` trx id 0 1285 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 8; hex 8000000000000005; asc         ;; 1: len 6; hex 000000000503; asc       ;; 2: len 7; hex 800000002d0110; asc     -  ;;

这是表上的一个新 IX 锁，加上唯一数据行上的一个“X 等待”锁。

原始线程可以对整个表或唯一的数据行运行更新，而不会出现死锁。

这是运行“5.1.37-1ubuntu5.1”，具有 REPEATABLE-READ。

见：

MySQL Manual - 13.6.8.1. InnoDB Lock Modes