博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
mysql中order by 和limit一起使用不当会导致效率极慢的4种优化方法
阅读量:6979 次
发布时间:2019-06-27

本文共 1196 字,大约阅读时间需要 3 分钟。

今天从慢查询发现一条语句查询时间达6秒。结果只查出一条记录。

原语句如下

SELECT
biz_order_id, buyer_id, buyer_nick, gmt_create, gmt_modified, attributeCc, seller_id
FROM trade.biz_order
WHERE shop_id=20484 AND STATUS=4 AND gmt_create >= '2017-10-30 16:34:42' AND order_type = 6
ORDER BY gmt_create DESC, biz_order_id DESC
LIMIT 0,100;
执行计划
shop_id都有索引可却走了时间gmt_create的索引,rows=861665
优化方法3种:
1:强制走shop_id索引
SELECT
biz_order_id, buyer_id, buyer_nick, gmt_create, gmt_modified, attributeCc, seller_id
FROM trade.biz_order force index(idx_shop_id)
WHERE shop_id=20484 AND STATUS=4 AND gmt_create >= '2017-10-30 16:34:42' AND order_type = 6
ORDER BY gmt_create DESC, biz_order_id DESC
LIMIT 0,100;
2:用子查询:
select * from ( SELECT biz_order_id, buyer_id, buyer_nick, gmt_create, gmt_modified, attributeCc, seller_id
FROM trade.biz_order
WHERE shop_id=20484 AND STATUS=4 AND gmt_create >= '2017-10-30 16:34:42' AND order_type = 6
ORDER BY gmt_create DESC, biz_order_id DESC) t
LIMIT 0,100;执行计划如上一样
3:调换order by中的两个条件顺序
ORDER BY biz_order_id DESC ,gmt_create DESC limit 0,100;换成这样。我发现这样执行计划的rows=1.9万效果更好。
4:还有一种方法删除
gmt_create列的索引,原理和方法3差不多。
总结:mysql中的order ,limit一起使用时的顺序是这样的和oracle不一样
order -->limit-->where条件
而常规一般是where-->order-->limit。

转载地址:http://loypl.baihongyu.com/

你可能感兴趣的文章
Linux --进程间通信--共享内存
查看>>
zookeeper集群环境搭建
查看>>
MySQL索引背后的数据结构及算法原理【转】
查看>>
用户登录
查看>>
这些编程语言程序员工资最高!Java才第四
查看>>
用shell分析nginx日志百度网页蜘蛛列表页来访情况
查看>>
类似ngnix的多进程监听用例
查看>>
高性能网站性能优化与系统架构(ZT)
查看>>
我的友情链接
查看>>
make报错:"/usr/bin/ld: cannot find -lXXX"
查看>>
GRUB2相关概念
查看>>
centos 6.4 SVN服务器多个项目的权限分组管理
查看>>
Anaconda中安装Orange3脚本-完整版
查看>>
Windows平台上实现P2P服务(三)
查看>>
nginx转发及后端服务器获取真实client的IP
查看>>
维护学习的一点体会与看法
查看>>
corosync+pacemaker+crm简单配置
查看>>
Linux学习笔记之文件管理和目录管理类命令
查看>>
综合技术 --@Autowired和@Resource
查看>>
SoapUI进行REST请求,POST方法提交到数据库的数据乱码问题
查看>>