1

我正在尝试调查我的应用程序中的死锁问题。我的桌子看起来像这样。

CREATE TABLE `requests` (
  `req_id` bigint(20) NOT NULL auto_increment,
  `status` varchar(255) default NULL,
  `process_id` varchar(200) default NULL,
  PRIMARY KEY  (`req_id`),
  KEY `status_idx` USING BTREE (`status`),
  KEY `pk_idx_requests` USING BTREE (`req_id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8
  • 服务（多线程）在此表上发出插入语句。

  • 多个客户端在两个单独的事务中按顺序发出以下查询。

    update requests set process_id='" + hostName + "' where status='Received' and process_id is null order by req_id asc limit 100"

    select * from requests where process_id='"+ hostName + "' where status='Received';

    更新请求 set status='Processing' where req_id='xyz'

第三个查询中的 Req_id 是从第二个查询中检索到的请求 ID 列表。

但有时在客户端，我们会看到以下异常。

Deadlock found when trying to get lock; try restarting transaction
org.hibernate.exception.LockAcquisitionException: could not execute native bulk manipulation query

上述查询是否会导致死锁，如果是，我们该如何解决？还有没有办法在本地重现这个问题？

这是“显示 innodb 状态”的输出

LATEST DETECTED DEADLOCK
------------------------
120507  6:03:21
*** (1) TRANSACTION:
TRANSACTION 115627, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1248, 25 row lock(s)
MySQL thread id 432399, OS thread handle 0x419e4940, query id 4111695 * * * Searching rows for update
update requests set process_id='**' where status='Received' and process_id is null order by req_id asc limit 100
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 4 page no 3797 n bits 136 index `PRIMARY` of table `db`.`requests` trx id 115627 lock_mode X locks rec but not gap waiting
Record lock, heap no 67 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
*** (2) TRANSACTION:
TRANSACTION 115626, ACTIVE 1 sec updating or deleting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 432403, OS thread handle 0x41c19940, query id 4111694 * * *  Updating
update requests set status='Processing', process_id='**' where req_id=3026296
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 4 page no 3797 n bits 136 index `PRIMARY` of table `db`.`requests` trx id 115626 lock_mode X locks rec but not gap
Record lock, heap no 67 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
4

2 回答 2

3

一些背景

MySQL 在第一次访问记录时对 UPDATE 语句进行写锁定。它不会将锁从读取提升到写入。它基于当前索引锁定。

在您的 UPDATE 语句中，MySQL 很可能使用状态列上的索引，因此 MySQL 会锁定 status = 'Received' 的每条记录。

请注意，只要您锁定多个唯一记录（使用唯一索引，例如主键），您就锁定了一个间隙（或范围）。

对单个记录的更新仍然需要下一个键锁，这意味着它会锁定所选记录和索引中的下一个记录。

同一索引上的两个 UPDATES（都具有下一个键）锁定不会冲突（它们将始终以相同的顺序锁定）。但是，由于您的范围锁定是针对二级索引的，因此它可能会死锁。

这是正在发生的情况：

假设您有两条记录，req_ids 为 1 和 2。

你的第一个事务根据状态索引更新，需要同时锁定记录 1 和记录 2，但不保证与主键顺序相同，所以它锁定记录 2，并且即将锁定记录 1。

您的第二个事务锁定 req_id 索引，需要更新记录 1。它立即锁定记录 1，但还需要对记录 2 执行 next-key 锁定。

这两个事务现在陷入僵局。事务 1 需要锁定记录 1，事务 2 需要锁定记录 2。

解决方案

为避免在您的情况下出现死锁，您可以使用 显式锁定整个表LOCK TABLES，或者在事务失败时简单地重试事务。MySQL 将检测到死锁，并且您的一个事务将被回滚。

MySQL 确实提供了一些说明来帮助您处理死锁。

您似乎还应该删除冗余键 pk_idx_requests，因为您的主键已经包含该列。

于 2012-05-07T20:49:00.300 回答
0

是的，这些查询可能会导致死锁。事实上，正如 MySQL 文档中所提到的，即使在仅插入或删除单行的事务的情况下，您也可能会出现死锁。了解如何应对死锁

您可以尝试索引 process_id 以尝试加快查询/更新。

于 2012-05-07T20:20:16.207 回答