一次应用'自动修复'的故障（mysql原因）

杭州的梅雨天，导致人不给力，可能系统也会出点问题...（我是DBA这个时候还在去公司的路上，下面的均为程序猿口述）

我司某个程序猿，早上的时候较为勤奋，来的比较早。这个时候，监控系统发出了很多报警信息，rabbitmq堵塞严重，积压了大量消息。他上堡垒机连接上应用服务器，tail 了error日志发现，业务系统没有任何问题。

然后统计下消息队列里面的信息。业务客户反映来看，只有信用卡的消费有影响，支付宝，WX都没问题。

运维去查了问题，发现并没有问题。运维准备重启系统，这个时候系统又突然好了，消息队列积压的消息少了。

（这个是程序猿在那个时间段查到的一个job的报错信息，PS：从我的角度来看这个就是锁争用导致的，至于是什么锁或者说为什么被锁就要具体分析，如果这个时候我在场，看下processlist，还有innodb lock，transaction相关的基表大概就能分析出是什么问题了，可惜堵车ing。。）

 

 

结尾：我给开发的回复就是有事务一直持有这lock,没有及时提交transaction，然后分析了一波上面那个SQL,是走的full type，至于为什么会好，这个是因为timeout机制。我这边能做的就是timeout时间减少，原先是默认的3600S。