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

Amio 发布于2019-08-06 12:25 / 1716人阅读

摘要：这台数据库的机器同时还跑其他业务，都是量级较大的，服务器负载本来就不低，七夕还没到，就因为这条把服务器搞的直冒烟，本业务慢查询也拖慢了其他业务的执行时间导致连锁反应。

喂？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秒内造成大量数据库慢查询。

直接说解决方案吧：

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

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

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

对数据库读取结果做缓存。

对接口结果做缓存。

做了这5步工作，妈妈再也不用担心我的服务器会冒烟啦~~

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

GPU云服务器云服务器如何搞一个自己的hyp加速专线如何把手机变成一个云服务器想搞一个云服务器编程用c语言搞一个心形

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/61704.html

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

摘要：这台数据库的机器同时还跑其他业务，都是量级较大的，服务器负载本来就不低，七夕还没到，就因为这条把服务器搞的直冒烟，本业务慢查询也拖慢了其他业务的执行时间导致连锁反应。喂？xxx吗？你们的服务怎么回事，机器又挂掉啦~！啊？挂掉几台了？你们借的40台挂了两台啦！骚等，我看看咋回事！服务器又冒烟了~~~原因是这样的：前段时间项目迎来七夕高峰，有一个接口的SQL本来长这样： mysql>...

lscho 2019-07-01 12:17 评论0 收藏0
SegmentFault 技术周刊 Vol.39 - 什么！服务器炸了？

摘要：有一次别人的云服务器被攻击，提供商竟然重启了物理机然后又诸多悲剧出现。造成微博服务短暂不可用。通过建立工具来诊断问题，并创建一种复盘事故的文化来推动并作出改进，防止未来发生故障。 showImg(https://segmentfault.com/img/bV0jif?w=900&h=385); 相信小伙伴们在上网或者玩游戏的时候一定都遇到过无法访问的情况。服务器炸了的原因有各种各样，下...

1treeS 2019-05-28 17:03 评论0 收藏0
留给传统 DBA 的时间不多了？看饿了么如何构建数据库平台自动化

摘要：因为传统的数据库管理方式在当前这种架构下依靠手工或者借助简单的工具是无法应对多活架构大规模管理带来的复杂性，因此平台化显得非常重。我们在做的方案时做了充分调查及论证，最终没有选择这种方式。蔡鹏，2015年加入饿了么，见证了饿了么业务&技术从0到1的发展过程，并全程参与了数据库及DBA团队高速发展全过程。同时也完成个人职能的转型-由运维DBA到DEV-DBA的转变,也从DB的维稳转变到专心为...

explorer_ddf 2019-04-25 17:21 评论0 收藏0
分表后需要注意的二三事

摘要：分表字段的选择。问题产生之前提到在分表应用上线前我们需要将原有表的数据迁移到新表中，这样才能保证业务不受影响。虽说凌晨的业务量下降，但依然有少部分的请求过来，也会出现各种数据库异常。 showImg(https://segmentfault.com/img/remote/1460000019462791?w=496&h=285); 前言本篇是上一篇《一次分表踩坑实践的探讨》，所以还没...

dongxiawu 2019-08-19 11:43 评论0 收藏0