某一天晚上服务发生报警,但是由于发生报警的时间过晚,到第二天开始查找问题原因,经排查,竟然发现是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并分析,确定原因后问题就很好解决了,希望以上经验可以帮助到你!!!