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