Mysql死锁问题Deadlock found when trying to get lock；try restarting transaction

原创已于 2024-01-12 18:55:59 修改 · 4.2k 阅读

22 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库

于 2024-01-08 14:06:03 首次发布

问题同时被 2 个专栏收录

16 篇文章

订阅专栏

Mysql

6 篇文章

订阅专栏

文章讲述了在测试环境中进行压测时遇到的MySQL死锁问题，涉及到两个事务因互相等待对方持有的排他锁导致的僵局。作者通过查看日志和代码分析，提出增加分布式锁来解决并发操作中的死锁问题。

一、问题描述

今天测试在测试环境做压测，发现了一个报错，来找我帮忙看，如下图：

二、问题排查

先去服务器上，看看死锁的日志，找到 mysql 的安装路径，使用如下命令登录 mysql

mysql -h 数据库IP地址 -P 数据库端口 -u 用户名 -p 库名

输入后，让你输入密码，输入密码之后，就登录成功了，然后再输入如下命令：

SHOW ENGINE INNODB STATUS \G

然后从中找到 LATEST DETECTED DEADLOCK 下面的内容，如下：

LATEST DETECTED DEADLOCK

2024-01-05 21:19:23 0x7f8269fed700
*** (1) TRANSACTION:
TRANSACTION 258666849, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 79628, OS thread handle 140195458455296, query id 9705658 10.100.0.95 root updating
update inc_t_store_return_merchandise_relation SET return_code=‘683901058240105_5’,

merchandise_code=‘60500085’,
apply_return_quantity=1,

returned_quantity=1,
return_unit_code=‘EA’,
returned_unit_code=‘EA’,
make_date=‘2024-01-01 08:00:00’,
batch_code=‘11’,

responsible_party=‘1’,
supplier_code=‘000159’,

price=600.00,

update_id=‘admin’,
update_time=‘2024-01-05 21:18:59.262’ where id=6701831480323817561 AND del_flag=‘N’

*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 9159 page no 31 n bits 128 index PRIMARY of table ■■■■■.inc_t_store_return_order trx id 258666849 lock_mode X locks rec but not gap
Record lock, heap no 61 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
0: len 8; hex 5d01b039393b4058; asc ] 99;@X;;
1: len 6; hex 00000f6af161; asc j a;;
2: len 7; hex 010000091f298d; asc ) ;;
3: len 17; hex 3638333930313035383234303130355f35; asc 683901058240105_5;;
4: len 3; hex 8fd025; asc %;;
5: len 1; hex 31; asc 1;;
6: len 7; hex 3130322d323036; asc 102-206;;
7: len 6; hex 303030313539; asc 000159;;
8: len 1; hex 31; asc 1;;
9: len 11; hex 315f363833393031303538; asc 1_683901058;;
10: SQL NULL;
11: SQL NULL;
12: len 1; hex 31; asc 1;;
13: len 4; hex e9998831; asc 1;;
14: len 2; hex 3320; asc 3 ;;
15: SQL NULL;
16: len 6; hex 313030313033; asc 100103;;
17: len 5; hex 99b24b549f; asc KT ;;
18: len 6; hex 313030313033; asc 100103;;
19: len 5; hex 99b24b549f; asc KT ;;
20: len 1; hex 4e; asc N;;
21: SQL NULL;
22: SQL NULL;
23: SQL NULL;
24: SQL NULL;
25: len 20; hex 36383339303130353832303234303130355f4532; asc 68390105820240105_E2;;
26: len 1; hex 32; asc 2;;

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 9158 page no 27 n bits 120 index PRIMARY of table ■■■■■.inc_t_store_return_merchandise_relation trx id 258666849 lock_mode X locks rec but not gap waiting
Record lock, heap no 53 PHYSICAL RECORD: n_fields 31; compact format; info bits 0
0: len 8; hex 5d01b039393b4059; asc ] 99;@Y;;
1: len 6; hex 00000f6af14e; asc j N;;
2: len 7; hex 020000112921bb; asc )! ;;
3: len 17; hex 3638333930313035383234303130355f35; asc 683901058240105_5;;
4: len 11; hex 315f363833393031303538; asc 1_683901058;;
5: len 8; hex 3630353030303835; asc 60500085;;
6: len 6; hex 800000010000; asc ;;
7: len 6; hex 800000010000; asc ;;
8: len 2; hex 4541; asc EA;;
9: len 3; hex 8fd021; asc !;;
10: len 2; hex 3131; asc 11;;
11: len 4; hex 80000001; asc ;;
12: len 1; hex 33; asc 3;;
13: SQL NULL;
14: SQL NULL;
15: len 6; hex 313030313033; asc 100103;;
16: len 5; hex 99b24b549f; asc KT ;;
17: len 5; hex 61646d696e; asc admin;;
18: len 5; hex 99b24b54bb; asc KT ;;
19: len 1; hex 4e; asc N;;
20: len 6; hex 303030313539; asc 000159;;
21: len 1; hex 31; asc 1;;
22: len 6; hex 303030313539; asc 000159;;
23: SQL NULL;
24: len 9; hex 800000000000025800; asc X ;;
25: len 9; hex 800000000000025800; asc X ;;
26: SQL NULL;
27: SQL NULL;
28: len 2; hex 4541; asc EA;;
29: len 9; hex 800000000000025800; asc X ;;
30: len 9; hex 800000000000000000; asc ;;

*** (2) TRANSACTION:
TRANSACTION 258666830, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 8 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 4
MySQL thread id 79129, OS thread handle 140195152140032, query id 9705666 10.100.0.95 root updating
UPDATE inc_t_store_return_order SET return_code=‘683901058240105_5’, return_date=‘2024-01-05 00:00:00’, return_type=‘2’, dc_code=‘102-206’, supply_institution_code=‘000159’, supply_delivery_type=‘1’, store_code=‘1_683901058’, confirm_user=‘admin’, confirm_time=‘2024-01-05 21:18:59.168’, check_flag=‘1’, status=‘5’, purchase_code=‘68390105820240105_E2’, return_way=‘2’, create_id=‘100103’, create_time=‘2024-01-05 21:18:31’, update_id=‘100103’, update_time=‘2024-01-05 21:18:31’ WHERE id=6701831480323817560 AND del_flag=‘N’

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 9158 page no 27 n bits 120 index PRIMARY of table ■■■■■.inc_t_store_return_merchandise_relation trx id 258666830 lock_mode X locks rec but not gap
Record lock, heap no 53 PHYSICAL RECORD: n_fields 31; compact format; info bits 0
0: len 8; hex 5d01b039393b4059; asc ] 99;@Y;;
1: len 6; hex 00000f6af14e; asc j N;;
2: len 7; hex 020000112921bb; asc )! ;;
3: len 17; hex 3638333930313035383234303130355f35; asc 683901058240105_5;;
4: len 11; hex 315f363833393031303538; asc 1_683901058;;
5: len 8; hex 3630353030303835; asc 60500085;;
6: len 6; hex 800000010000; asc ;;
7: len 6; hex 800000010000; asc ;;
8: len 2; hex 4541; asc EA;;
9: len 3; hex 8fd021; asc !;;
10: len 2; hex 3131; asc 11;;
11: len 4; hex 80000001; asc ;;
12: len 1; hex 33; asc 3;;
13: SQL NULL;
14: SQL NULL;
15: len 6; hex 313030313033; asc 100103;;
16: len 5; hex 99b24b549f; asc KT ;;
17: len 5; hex 61646d696e; asc admin;;
18: len 5; hex 99b24b54bb; asc KT ;;
19: len 1; hex 4e; asc N;;
20: len 6; hex 303030313539; asc 000159;;
21: len 1; hex 31; asc 1;;
22: len 6; hex 303030313539; asc 000159;;
23: SQL NULL;
24: len 9; hex 800000000000025800; asc X ;;
25: len 9; hex 800000000000025800; asc X ;;
26: SQL NULL;
27: SQL NULL;
28: len 2; hex 4541; asc EA;;
29: len 9; hex 800000000000025800; asc X ;;
30: len 9; hex 800000000000000000; asc ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 9159 page no 31 n bits 128 index PRIMARY of table ■■■■■.inc_t_store_return_order trx id 258666830 lock_mode X locks rec but not gap waiting
Record lock, heap no 61 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
0: len 8; hex 5d01b039393b4058; asc ] 99;@X;;
1: len 6; hex 00000f6af161; asc j a;;
2: len 7; hex 010000091f298d; asc ) ;;
3: len 17; hex 3638333930313035383234303130355f35; asc 683901058240105_5;;
4: len 3; hex 8fd025; asc %;;
5: len 1; hex 31; asc 1;;
6: len 7; hex 3130322d323036; asc 102-206;;
7: len 6; hex 303030313539; asc 000159;;
8: len 1; hex 31; asc 1;;
9: len 11; hex 315f363833393031303538; asc 1_683901058;;
10: SQL NULL;
11: SQL NULL;
12: len 1; hex 31; asc 1;;
13: len 4; hex e9998831; asc 1;;
14: len 2; hex 3320; asc 3 ;;
15: SQL NULL;
16: len 6; hex 313030313033; asc 100103;;
17: len 5; hex 99b24b549f; asc KT ;;
18: len 6; hex 313030313033; asc 100103;;
19: len 5; hex 99b24b549f; asc KT ;;
20: len 1; hex 4e; asc N;;
21: SQL NULL;
22: SQL NULL;
23: SQL NULL;
24: SQL NULL;
25: len 20; hex 36383339303130353832303234303130355f4532; asc 68390105820240105_E2;;
26: len 1; hex 32; asc 2;;

*** WE ROLL BACK TRANSACTION (1)

可以看到事务1在根据主键ID更新 inc_t_store_return_merchandise_relation 表，而它持有 inc_t_store_return_order 表的排他锁（lock_mode X），而事务2在根据主键ID更新 inc_t_store_return_order 表，而它持有 inc_t_store_return_merchandise_relation 表的排他锁（lock_mode X），相当于两个事务都在等对方持有的排他锁，于是就死锁了。

去看了下代码，操作步骤如下

1、根据主键ID更新 inc_t_store_return_merchandise_relation 表

2、根据主键ID更新 inc_t_store_return_order表

3、根据主键ID更新 inc_t_store_return_merchandise_relation 表