[大数据]一条慢SQL拖死整个系统

1.自身案例

前几天监控探针突然告警，手动调用生产接口发现特别慢，平时A服务中几百毫秒就能响应的接口变成了3-5秒，慢的时候十几秒，有时候还直接超时。

首先查看相关服务，发现A服务cpu和内存都正常，服务日志也正常在输出，排除了服务问题，我一度认为是网络有波动，没有找到原因，直接重启服务，问题没有得到解。

直到后来有人说数据库是否有问题，然后查看数据库，果然发现一堆update语句卡住了在等待执行，然后一看update 的where条件，这个字段没有索引，原因找到了，就是因为更新条件没有索引，导致update语句特别慢，这里的业务又是批量更新，一瞬间会有大量的更新语句进入到sql，导致数据库资源被大量消耗，从而影响了整个服务（这个update语句是B服务，即B服务的慢sql占用了大量的数据库资源，从而导致其他所有服务响应都变慢）。

检查到原因后就给对应的字段添加了索引，然后就变快了，服务逐渐恢复稳定。（注意这里直接加索引，同时又源源不断的有这个语句进入数据库的话我认为是有可能会导致锁表的，由于这个业务特殊，只有少数人用，我直接电话通知他们停止使用，然后再添加索引）

注意：这里慢sql是update语句，我本来想让DBA直接kill的，但是由于是update语句DBA也不敢kill，说只能做回滚操作，如果是select语句，则直接kill。

这里我还有一个思路就是，先停用该接口，防止大量的update语句继续进入数据库，然后再加索引，所以可以在系统中添加一个开关，配置这个接口是否开启，随时可以启停某个接口，当某个接口出现问题时，直接停掉，然后抓紧时间解决，再启用接口。

2.在网上找到的几个类似的案例，记录一下

1. 案例：一条慢SQL拖死整个系统

某天突然发现服务探测接口疯狂告警、同时数据库CPU消耗也告警，最后系统都无法访问；

起先以为服务出现问题，服务重启后现象依旧；

后检查数据库发现，大量的慢SQL正在阻塞等待执行：

查看哪些表被锁：show OPEN TABLES where In_use > 0;

查询正在执行的SQL，发现大量SQL执行阻塞了几百秒

select * from information_schema.processlist where db=‘ db_xxx ‘ and info is not null;

直接取出索引的进程ID，拼装成kill语句，取出来执行，干掉阻塞中的索引进程。

select concat(‘kill ‘, id,‘;‘) from information_schema.processlist where db=‘db_xxx ‘ and info is not null;

发现干掉一次之后，很快又出现大量的执行阻塞的SQL，而且90%以上都是某一条SQL。

干掉N次之后仍然不行，还是会出现。。。。。。

将该条执行的SQL扒出来，针对查询条件，创建了组合索引，SQL阻塞现象消失，

系统也恢复了正常。。。。。

参考：MySQL优化5之CPU消耗过高（一条慢SQL拖死整个系统）