登录
首页 >  数据库 >  MySQL

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

来源:SegmentFault

时间:2023-01-28 15:58:22 248浏览 收藏

积累知识,胜过积蓄金银!毕竟在##column_title##开发的过程中,会遇到各种各样的问题,往往都是一些细节知识点还没有掌握好而导致的,因此基础知识点的积累是很重要的。下面本文《如何不让一个慢查询把服务器搞冒烟》,就带大家讲解一下MySQL、PHP、Memcached知识点,若是你对本文感兴趣,或者是想搞懂其中某个知识点,就请你继续往下看吧~

喂?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移到这里来,以后主要在这写啦。

到这里,我们也就讲完了《如何不让一个慢查询把服务器搞冒烟》的内容了。个人认为,基础知识的学习和巩固,是为了更好的将其运用到项目中,欢迎关注golang学习网公众号,带你了解更多关于mysql的知识点!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表