Innodb 死锁，看起来像 tx 锁定了自己

Posted 2023-03-23

【中文标题】Innodb 死锁，看起来像 tx 锁定了自己

【英文标题】：Innodb deadlock, looks like tx locks itself

【发布时间】：2017-04-13 11:30:53

【问题描述】：

我收到一个死锁错误，但不明白为什么。下面的报告显示，第二个事务（..453，即回滚）已经锁定 “空间 id 545 页号 7185 n 位 192 索引 PRIMARY 表 orders.order_items " 和 等待锁定完全相同。

第一个，...455也想拿到同一个锁，但是可以等，没问题...

所以看起来事务 ..453 锁定了自己？？

------------------------
LATEST DETECTED DEADLOCK
------------------------
2017-04-13 10:55:21 7f434dd30700
*** (1) TRANSACTION:
TRANSACTION 108696455, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1184, 4 row lock(s), undo log entries 2
MySQL thread id 652170, OS thread handle 0x7f434ca25700, query id 268182543 10.9.14.13 orders updating
delete from order_items where id=13828382 and version='2017-04-11 12:28:02'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 545 page no 7185 n bits 192 index `PRIMARY` of table `orders`.`order_items` trx id 108696455 lock_mode X locks rec but not gap waiting
*** (2) TRANSACTION:
TRANSACTION 108696453, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1184, 7 row lock(s), undo log entries 5
MySQL thread id 652151, OS thread handle 0x7f434dd30700, query id 268182547 10.9.14.11 orders updating
delete from order_items where id=13828386 and version='2017-04-11 12:28:02'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 545 page no 7185 n bits 192 index `PRIMARY` of table `orders`.`order_items` trx id 108696453 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 545 page no 7185 n bits 192 index `PRIMARY` of table `orders`.`order_items` trx id 108696453 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (1)

编辑：表创建代码：

CREATE TABLE `order_items` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_id` bigint(20) DEFAULT NULL,
  `catalog_number` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `posex` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `sap_item_name` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `currency` varchar(3) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `status` varchar(20) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `price` decimal(19,2) DEFAULT NULL,
  `quantity` decimal(19,10) DEFAULT NULL,
  `parent_item_posex` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `deleted` bit(1) DEFAULT NULL,
  `version` datetime NOT NULL,
  `created_date` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `FKbioxgbv59vetrxe0ejfubep1w` (`order_id`),
  CONSTRAINT `FKbioxgbv59vetrxe0ejfubep1w` FOREIGN KEY (`order_id`) REFERENCES `orders` (`id`),
  CONSTRAINT `order_items_ibfk_1`          FOREIGN KEY (`order_id`) REFERENCES `orders` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14564054 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

【问题讨论】：

请提供SHOW CREATE TABLE order_items。

嗨@RickJames，我已经添加了创建代码，感谢您的检查！

猜测：2 个相同的 FK 约束？

谢谢@RickJames，看起来是这样......

运气不好，@RickJames，不是那样...同样的僵局情况再次发生...

【参考方案1】：

正如 Rick James 猜测的那样，它看起来只是一把相同的双钥匙。至少在删除其中一个约束后，该表不再出现问题。

【讨论】：

“每天学习新东西。”这真是一个猜测。

这也让我感到惊讶，因为死锁报告表明主键有问题，而不是外键。但与此同时，我了解到这些报告通常具有很大的误导性......