如何不让一个慢查询把服务器搞冒烟

喂？xxx吗？大家的服务怎么回事，机器又挂掉啦~！
啊？挂掉几台了？
大家借的40台挂了两台啦！
骚等，我看看咋回事！

服务器又冒烟了~~~缘由是这样的：

前段时间项目迎来七夕高峰，有一个接口的SQL原本长这样：

mysql> explain SELECT *,sum(num) AS sum FROM search WHERE search_time >= '2016-08-30' AND type = 0 AND state = 1 GROUP BY keyword ORDER BY sum DESC LIMIT 50;
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+
| id | select_type | table     | type | possible_keys            | key  | key_len | ref   | rows   | Extra                                        |
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+
|  1 | SIMPLE      | search | ref  | type,search_time,keyword | type | 2       | const | 651114 | Using where; Using temporary; Using filesort |
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+

search_time,type,state都建了索引，type和state取值范围有限，因此基本没啥用，主要是靠search_time，可是explain的结果表示并无用到有效索引，实际状况下表里有130w+数据的时候这个语句跑起来平均耗时5s多，这确定是不能忍受的。

那强制索引怎么样？试试看：

mysql> explain SELECT *,sum(num) AS sum FROM search FORCE INDEX (search_time) WHERE search_time >= '2016-08-30' AND type = 0 AND state = 1 GROUP BY keyword ORDER BY sum DESC LIMIT 50;
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+
| id | select_type | table     | type  | possible_keys       | key         | key_len | ref  | rows   | Extra                                                               |
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+
|  1 | SIMPLE      | search | range | search_time,keyword | search_time | 4       | NULL | 290616 | Using index condition; Using where; Using temporary; Using filesort |
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+

有效果，rows降到29w，照理说在29w里面怎么查都不会太慢，可是都知道explain里的rows只是个参考，实际跑起来仍是花了3s多，也是不能忍受的。

这台数据库的机器同时还跑其余业务，都是量级较大的，服务器负载原本就不低，七夕还没到，就由于这条sql把服务器搞的直冒烟，本业务慢查询也拖慢了其余业务的执行时间致使连锁反应。

以前已经对数据的读取部分加了缓存，可是日志记录仍是显示某段时间内产生大量的慢查询请求。开始咱们怀疑是缓存失效，但后来发现，实际上是高并发致使在设置缓存阶段，因为sql语句执行时间太长，致使在这5秒内形成大量数据库慢查询。

直接说解决方案吧：

1. 缩小查询范围，由以前的查询3天改成查询1天，量级降到130w+数据。

2. 强制使用索引，必定程度上缩短查询时间。

3. 写个脚本，定时将查询结果保存到memcache里，这个主要是防止高并发状况下，等待写入mc时形成短期大量数据库访问。

4. 对数据库读取结果作缓存。

5. 对接口结果作缓存。

作了这5步工做，妈妈不再用担忧个人服务器会冒烟啦~~

注：后面会慢慢把其余blog移到这里来，之后主要在这写啦。