Mysql死锁，问题定位及解决。

最新推荐文章于 2024-09-03 09:30:00 发布

Chou_Yuan

最新推荐文章于 2024-09-03 09:30:00 发布

阅读量549

点赞数

分类专栏： mysql 文章标签： mysql

本文链接：https://blog.csdn.net/Chou_Yuan/article/details/105991226

版权

本文分析了MySQL5.7版本InnoDB引擎出现的死锁问题，通过show innodb status日志发现两条SQL语句（update和replace into）之间的锁竞争。解决方法是将update语句的条件修改为包含联合索引的所有字段，以减少锁的范围，避免死锁的发生。

摘要由CSDN通过智能技术生成

本文中，MySQL5.7版本，InnoDb引擎。
通过日志监控发现，线上环境发生死锁，show innodb status 日志内容如（只截取了一小段日志）：

2020/4/22 1:29,InnoDB: *** WE ROLL BACK TRANSACTION (1)
2020/4/22 1:29,InnoDB: 
2020/4/22 1:29,InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
2020/4/22 1:29,InnoDB: *** (2) HOLDS THE LOCK(S):
2020/4/22 1:29,InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
2020/4/22 1:29,"InnoDB: Transactions deadlock detected, dumping detailed information."
2020/4/22 1:29,InnoDB: *** (2) TRANSACTION:
2020/4/22 1:29, 4: len 7; hex 56000001791902; asc V   y  ;;
2020/4/22 1:29, 5: len 3; hex 800066; asc   f;;
2020/4/22 1:29, 6: len 4; hex de9eb610; asc     ;;
2020/4/22 1:29,update table_name set xxx= 0 where userId = 45987
2020/4/22 1:29,"Record lock, heap no 313 PHYSICAL RECORD: n_fields 10; compact format; info bits 0"
2020/4/22 1:29, 9: len 1; hex 80; asc  ;;
2020/4/22 1:29, 4: len 7; hex 56000001791902; asc V   y  ;