mysql死锁分析

请提供表DDL和事务过程

事务2是等待被授予锁，状态是 "WAITING FOR THIS LOCK TO BE GRANTED"

yejr 发表于 2025-1-3 17:35
请提供表DDL和事务过程

DDL:
CREATE TABLE `test01` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `batch_id` bigint unsigned NOT NULL DEFAULT '0',
  `original_image_id` bigint unsigned NOT NULL DEFAULT '0',
  `corrected_image_id` bigint unsigned NOT NULL DEFAULT '0',
  `correct_status` tinyint NOT NULL DEFAULT '0',
  `failed_times` int unsigned NOT NULL DEFAULT '0',
  `last_correct_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `next_retry_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `is_del` tinyint unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`uidpk`),
  KEY `idx_correcttime_status` (`last_correct_time`,`correct_status`),
  KEY `idx_status` (`correct_status`)
) ENGINE=InnoDB AUTO_INCREMENT=1193449 DEFAULT CHARSET=utf8mb3
事务过程：
事务一、事务二分别同时执行日志中的sql即可

yejr 发表于 2025-1-3 17:42
事务2是等待被授予锁，状态是 "WAITING FOR THIS LOCK TO BE GRANTED"

事务二的HOLDS THE LOCK中有对idx_status持有锁
2024-12-01T11:46:53.975391+08:00 0 [Note] [MY-012469] [InnoDB]  *** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1752 page no 6497 n bits 1168 index idx_status of table `as_main`.`correct_batch_task` trx id 1648345461 lock_mode X
Record lock, heap no 1015 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 8; hex 00000000000f867d; asc        };;

Record lock, heap no 1031 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 8; hex 00000000000f8689; asc         ;;

Record lock, heap no 1034 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 8; hex 00000000000f8678; asc        x;;

Record lock, heap no 1041 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 8; hex 00000000000f8680; asc         ;;

Record lock, heap no 1057 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 8; hex 00000000000f868a; asc         ;;

zj5220924 发表于 2025-1-3 17:48
事务二的HOLDS THE LOCK中有对idx_status持有锁
2024-12-01T11:46:53.975391+08:00 0 [Note] [MY-012469] ...

事务2持有的是对 idx_status 索引上的锁，对应的锁记录是
0: len 1; hex 81; asc  ;;
1: len 8; hex 00000000000f868a; asc         ;;

等待的锁记录是 PRIMARY 上的
0: len 8; hex 00000000000f868a; asc         ;;

二者并不是同一条记录。

yejr 发表于 2025-1-3 17:59
事务2持有的是对 idx_status 索引上的锁，对应的锁记录是
0: len 1; hex 81; asc  ;;
1: len 8; hex 0000 ...

虽然一个是idx_status索引上面的锁，一个是primary上面的锁，但是他们都指向同一条数据，
比如下面这个指向的就是主键为00000000000f868a的记录：
0: len 1; hex 81; asc  ;;
1: len 8; hex 00000000000f868a; asc         ;;
既然事务一已经拿到这条记录的主键索引锁，那idx_status肯定已经获取了，事务还未结束，索引锁都还未释放，那么事务二是如何获取到并持有dix_status对应该条数据的锁的呢

zj5220924 发表于 2025-1-3 18:34
虽然一个是idx_status索引上面的锁，一个是primary上面的锁，但是他们都指向同一条数据，
比如下面这个指 ...

对innodb的索引结构你理解有误，可以先看看这篇文章 https://mp.weixin.qq.com/s/sFaQ2dFIvZk7ujUuC6x70A

zj5220924 发表于 2025-1-3 18:34
虽然一个是idx_status索引上面的锁，一个是primary上面的锁，但是他们都指向同一条数据，
比如下面这个指 ...

从应用上查一下,是不是事务前面还执行了什么SQL.