记一次order by desc limit导致的查询慢

昨天接到一个客户的问题,电脑上可以打开网站,在手机上确不能打开报500的错。首先登陆上客户的服务器查看环境apache+mysql+php,php和mysql的占用都比较高,按经验来说那就是mysql的问题了,登陆mysql用show processlist查看进程,发现一条查询一直在sending date

mysql> show processlist;
+------+------+-----------------+--------+---------+------+--------------+------
--------------------------------------------------------------------------------
----------------+
| Id   | User | Host            | db     | Command | Time | State        | Info

                |
+------+------+-----------------+--------+---------+------+--------------+------
--------------------------------------------------------------------------------
----------------+
| 1832 | root | localhost:53490 | NULL   | Query   |    0 | NULL         | show
processlist
                |
| 1842 | root | localhost:53508 | yungou | Query   |    4 | Sending data | selec
t a.id,a.q_user,a.q_showtime,a.thumb,a.title,a.q_uid,qishu,announced_type,q_end_
time ,(SELECT ` |
+------+------+-----------------+--------+---------+------+--------------+------
--------------------------------------------------------------------------------
----------------+
2 rows in set (0.00 sec)

明显不对啊,把这条语句单独拿出来执行也是慢得要死48s。

explain分析一下这条语句:

mysql> explain select a.id,a.q_user,a.q_showtime,a.thumb,a.title,a.q_uid,qishu,a
nnounced_type,q_end_time ,(SELECT `time` FROM `go_member_go_record` WHERE shopid
 = a.id ORDER BY `time` DESC LIMIT 1 ) as gm_time from `go_shoplist` as a where
`shenyurenshu` <=0 ORDER BY `gm_time` DESC LIMIT 4\G;
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: a
         type: range
possible_keys: shenyurenshu
          key: shenyurenshu
      key_len: 4
          ref: NULL
         rows: 945
        Extra: Using where; Using filesort
*************************** 2. row ***************************
           id: 2
  select_type: DEPENDENT SUBQUERY
        table: go_member_go_record
         type: index
possible_keys: shopid
          key: time
      key_len: 63
          ref: NULL
         rows: 1
        Extra: Using where
2 rows in set (0.00 sec)

一看type是range就悲剧了,慢是肯定的了,但是945条记录也不至于这么慢啊!!

没办法用简化法来定位错误,先去掉子查询,直接

select a.id,a.q_user,a.q_showtime,a.thumb,a.title,a.q_uid,qishu,announced_type,q_end_time from `go_shoplist` as a where `shenyurenshu` <=0 ORDER BY `gm_time` DESC LIMIT 4;

没有问题,速度杠杠的~~

那就是子查询的问题了哦,从哪里动刀呢?order by desc limit

首先去掉排序,查询杠杠的~~

然后想想order by desc limit 1怎么替代呢,这句的意思是查询最大的值,那我直接用max可以吗?马上修改

select a.id,a.q_user,a.q_showtime,a.thumb,a.title,a.q_uid,qishu,announced_type,q_end_time ,(SELECT MAX(`time`) FROM `go_member_go_record` WHERE shopid = a.id ) as gm_time from `go_shoplist` as a where `shenyurenshu` <=0 ORDER BY `gm_time` DESC LIMIT 4;

打开网站,哈哈,速度杠杠的~~

时间: 2024-08-07 08:39:55

记一次order by desc limit导致的查询慢的相关文章

单表查询: where group by 分组 having distinct 去重 order by 排序 limit 多表查询 子查询 连表查询

今日内容 表查询 单表查询: where group by 分组 having distinct 去重 order by 排序 limit 多表查询 子查询 连表查询 单表查询 前期表准备 create table emp( id int not null unique auto_increment, name varchar(20) not null, sex enum('male','female') not null default 'male', #大部分是男的 age int(3) u

NumberFormatException: Invalid int类型不匹配异常——使用SQL数据库查询语句select * from blacknumber order by _id desc limit ?,20;出现

异常:类型不匹配 05-06 08:12:38.151: E/AndroidRuntime(14904): java.lang.NumberFormatException: Invalid int: "18600000099" 05-06 08:12:38.151: E/AndroidRuntime(14904): at com.itheima.mobilesafe74.activity.BlackNumberActivity$Myadapter.getView(BlackNumber

记一次由于引用第三方服务导致的GC overhead limit exceeded异常

最近笔者遇到一个问题  监控平台忽然告警 GC overhead limit exceeded 这个异常 第一反应估计是堆溢出了.于是各种各种jmap  jstack下载堆栈文件和堆日志文件. 以下是线程堆栈dump下来的日志文件 p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px "Helvetica Neue"; color: #0433ff } span.s1 { font: 12.0px ".PingFang SC

11_查询之order by和limit

select 5种子句: where 条件查询 group by 分组 having 筛选 order by 排序 limit 限制结果条数 --------------------- order by 排序 默认是升序asc 想要按降序排 desc 可以按多字段排序,如: order by 字段1 asc/desc,字段2 asc/desc; 取出所有商品,按价格从低到高:(默认) select goods_id,goods_name,shop_price from goods order b

Mysql order by与limit混用陷阱

在Mysql中我们常常用order by来进行排序,使用limit来进行分页,当需要先排序后分页时我们往往使用类似的写法select * from 表名 order by 排序字段 limt M,N.但是这种写法却隐藏着较深的使用陷阱.在排序字段有数据重复的情况下,会很容易出现排序结果与预期不一致的问题. 比如现在有一张user表,表结构及数据如下: 表结构 表数据 现在想根据创建时间升序查询user表,并且分页查询,每页2条,那很容易写出sql为:select * from user orde

Mysql的ORDER BY 和Limit offset的一个问题,拿出来和大家研究下

今天碰到个很怪异的问题,如题关于mysql的ORDER BY 语句和Limit offset语句问题. bug再现下:select * from A a where a.culomn1 limit 5 offset 0 order by a.culomn1 asc 则出现sqlException,提示order by 这行有问题. 若将语句改为如下,将limit语句和order by 语句调换: select * from A a where a.culomn1 order by a.culom

mysql同时使用order by和limit查询时的一个严重隐患 -- 丢失数据

我经常使用order by和limit来做数据分页显示并排序,一直也没发现过什么问题.但这两天缺遇到一个严重的问题,在按时间戳升序排列并用limit分批读取数据时,却发现在某些记录丢失了,表中明明有的记录确死活读取不到.研究了大半天终于发现了问题所在,记录一下以防忘记,也是给大家提个醒. 问题重现 工具和原料 数据库: Ver 14.14 Distrib 5.6.11, for Linux (x86_64) using EditLine wrapper 表结构: 字段 类型 说明 id int(

表上触发器导致慢查询

触发器导致慢查询情况说明:慢日志每天几乎同一时刻都会有一条删除的慢查询,而且语句一样,除了日期.然后发现表上只有一个主键,没有其它索引,看执行计划是全表扫描,但count一下总共也就900多行,执行3秒钟,不能忍.给表上这个时间字段加上索引,删除是按照时间删的,看着扫描行数下来了,但是一执行还是3秒多,啥情况? 我把整张表dump出来,准备在自己删的差不多时候,再导回来.无意间打开导出的sql,发现该表上有一个删除行之后执行的触发器. 然后我就把触发器删除了,发现执行删除sql就很快,而且全表扫

字符串与时间使用+操作符导致数据库查询返回空

问题描述:在现场客户安装好软件后,在系统中查询不到任何的记录,但是在数据库表中确实有记录存在的.而且有很多其他的现场都没有出现问题,在测试阶段也没有过. 分析:后台查询的sql语句采用了类似拼接的方式,比如“select * from tableA where startTime>”+Datetime.在这里就会有很大的一些隐患了(在现场出现问题以后才发现了): 第一.字符串与其他类型的变量在采用+拼接的时候,实际上采用了toString()的方法,而toString()返回的字符格式会受系统的