MySQL死锁分析:记一次因索引合并导致的MySQL死锁分析过程

这篇博客详细分析了一次由于索引合并导致的MySQL死锁问题。作者通过查看事务和锁定记录,发现两个事务在尝试获取彼此已持有的锁,从而形成循环等待,导致死锁。尽管更新的是同一张表的不同记录,且来自同一个用户,但事务间的加锁顺序不同造成了死锁。经过分析,作者排除了消息重发作为死锁原因的可能性,并推测在用户同时偿还多笔贷款时可能出现此类死锁,但未能在测试环境中复现该问题。
摘要由CSDN通过智能技术生成

TRANSACTION 424487272, ACTIVE 0 sec fetching rows

mysql tables in use 3, locked 3

LOCK WAIT 6 lock struct(s), heap size 1184, 4 row lock(s)

MySQL thread id 3205005, OS thread handle 0x7f39c21c8700, query id 567774892 10.14.34.30 finance Searching rows for update

update repay_plan_info_1

SET actual_pay_period_amount = 38027,

actual_pay_principal_amount = 36015,

actual_pay_interest_amount = 1980,

actual_pay_fee = 0,

actual_pay_fine = 32,

actual_discount_amount = 0,

repay_status = ‘PAYOFF’,

repay_type = ‘OVERDUE’,

actual_repay_time = ‘2019-08-12 15:48:15.025’

WHERE ( user_id = ‘938467411690006528’

and loan_order_no = ‘LN201907120655461690006528458116’

and seq_no = 1

and repay_status <> ‘PAYOFF’ )

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 3680 page no 30 n bits 136 index PRIMARY of table db_loan_core_2.repay_plan_info_1 trx id 424487272 lock_mode X locks rec but not gap waiting

Record lock, heap no 64 PHYSICAL RECORD: n_fields 33; compact format; info bits 0

0: len 8; hex 800000000000051e; asc ;;

1: len 6; hex 0000193d35df; asc =5 ;;

2: len 7; hex 06000001d402e7; asc ;;

3: len 30; hex 323031393036313332303532303634323936303534323130353730303030; asc 201906132052064296054210570000; (total 32 bytes);

4: len 30; hex 4c4e32303139303631333031323934303136393030303635323831373534; asc LN2019061301294016900065281754; (total 32 bytes);

5: len 4; hex 80000002; asc ;;

6: len 18; hex 393338343637343131363930303036353238; asc 9384

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值