记一次死锁问题排查

前言

某一天晚上服务发生报警,但是由于发生报警的时间过晚,到第二天开始查找问题原因,经排查,竟然发现是mysql死锁导致的!!!

一、原因分析

2021-12-28 深夜,我负责的服务发生报警,通过查看错误日志,发现是mysql死锁导致的,如图:
在这里插入图片描述
次日上午,通过查看sql:DELETE FROM table WHERE update_time < DATE_ADD(NOW(),INTERVAL -? SECOND),确定代码报错的地方如下:
在这里插入图片描述
看原因是死锁导致的,初步怀疑是在同一时刻有其他事务对该表的数据做处理,于是马上联系DBA处理,让他帮忙执行show engine innodb status 查看innodb引擎时间信息,用于进行死锁的分析,之后DBA把死锁分析的日志截图给我,如下:
在这里插入图片描述
然后查询该表的索引:
在这里插入图片描述
可以看到该表有i_u普通索引和i_g_k_v联合索引;

原因分析:
可以看到该表有i_u普通索引和i_g_k_v联合索引也就是非主键索引;

(1)死锁日志里可以看到,事务1开始索引读,锁定i_u索引,等待主键索引的锁去执行delete操作;

(2)事务2持有三个字段的联合索引锁,会先锁住i_g_k_v索引,再根据主键去更新,获取主键上的行级锁,等待i_u索引去执行更新操作;

(3)这样就是事务1锁定了i_u索引,等待主键索引,事务2锁定i_g_k_v索引和主键索引,等待i_u索引,这样造成了互相等待(指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象),就导致了死锁。

二、解决方案

优化事务1的sql,先根据时间查出符合条件的主键值,再按照主键更新记录
在这里插入图片描述
以上sql用以下替代:
在这里插入图片描述
优化后观察一段时间,之前的问题没有再出现了,问题得已解决😄😄😄

总结

以上问题首先可以了解下死锁产生的原因,然后查到具体的sql并分析,确定原因后问题就很好解决了,希望以上经验可以帮助到你!!!

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值