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

原创 2016年08月31日 14:39:10

手机API接口如何抗住高并发

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

mysql> explain SELECT *,sum(num) AS sum FROM bi_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      | bi_search | ref  | type,search_time,keyword | type | 2       | const | 651114 | Using where; Using temporary; Using filesort |
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+

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

那强制索引怎么样?试试看:

mysql> explain SELECT *,sum(num) AS sum FROM bi_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      | bi_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. 对接口结果做缓存
版权声明:本文为博主原创文章,未经博主允许不得转载。

一个用户SQL慢查询分析,原因及优化

问题描述 一个用户反映线上一个SQL语句执行时间慢得无法接受。SQL语句看上去很简单(本文描述中修改了表名和字段名): SELECT count(*) FROM a JOIN b ON a...

mysql慢查询工具Anemometer

  • 2015年12月17日 10:45
  • 529KB
  • 下载

最近根据别人提示的一个想法,东拼西凑,终于实现了android系统中只能看到自己的系统,我称之为唯一系统。 很多企业做设备或是做产品的或是集成商 其中的一部分设备直接用android智能机。担是又不让

最近根据别人提示的一个想法,东拼西凑,终于实现了android系统中只能看到自己的系统,我称之为唯一系统。 很多企业做设备或是做产品的或是集成商 其中的一部分设备直接用android智能机。担是又不...

一个不让按的按钮(3KB)

  • 2006年02月23日 09:05
  • 3KB
  • 下载

数据库调优教程(一)前言&慢查询定义

最近帮公司优化数据库,凭着之前所学,一步一步地将学习知识用于实践,总算是将速度蹭上去了,一个原本要执行1分多钟的查询现在只需要3秒。 现把自己所学所思及所用加以总结,一方面为自己巩固知识,另一方面也给...

mysql 优化之开启慢查询并分析原因

开启mysql慢查询日志 查看配置:

PostgreSQL 慢查询SQL语句跟踪

示例:启用 SQL 跟踪 PostgreSQL 支持集中格式输出 stderr(默认), csvlog , syslog 一般的错误跟踪,只需在配置文件 【postgresql.conf】简单设...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:如何不让一个慢查询把服务器搞冒烟
举报原因:
原因补充:

(最多只允许输入30个字)