mysql limit asc_MySql sql优化之order by desc/asc limit M-阿里云开发者社区
Order by desc/asc limit M是我在mysql sql优化中经常遇到的一种场景,其优化原理也非常的简单,就是利用索引的有序性,优化器沿着索引的顺序扫描,在扫描到符合条件的M行数据后,停止扫描;看起来非常的简单,但是我经常看到很多性能较差的sql没有利用这个优化规律,下面将结合一些实际的案例来分析说明:
案例一:
一条sql执行非常的慢,执行时间为:
root@test 02:00:44
SELECT * FROM test_order_desc WHERE END_TIME>now() ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
+---------+-----------+------------+------+---------------------+---------------------+-------------------
Data1.....................................................................................................
Data2.....................................................................................................
+---------+-----------+------------+------+---------------------+---------------------+-------------------
12 ROWS IN SET (0.49 sec)
执行计划如下:
root@test_db01:53:23
EXPLAIN SELECT * FROM test_order_desc WHERE END_TIME > now()
ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----
| id | select_type | TABLE | TYPE | possible_keys | KEY | key_len | REF | ROWS | Extra |
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----
| 1 | SIMPLE | test_order_desc | range | ind_hot_endtime | ind_hot_endtime | 9 | NULL | 113549 | USING WHERE; USING filesort |
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----
Ind_hot_endtime索引为:
root@test_db01:52:45:SHOW INDEX FROM test_order_desc;
Ind_hot_endtime(end_time,count_num)
在注意到sql中满足过滤条件end_time>now()的有113549行,在加上剩余的条件中含有order by,这样会造成排序的结果集非常的大,执行非常的耗费资源;于是分析sql,在sql中包括了order by desc limit这样的排序条件后,新增适当的索引满足排序的条件,同时由于有limit的限制结果集,当扫描到满足条件的行数后退出查询,那么我们来看看优化效果:
添加索引:
root@test 02:01:06:ALTER TABLE test_order_desc ADD INDEX ind_gmt_create(gmt_create,count_num);
Query OK, 211945 ROWS affected (6.71 sec)
Records: 211945 Duplicates: 0 Warnings: 0
再次执行sql,观察其执行时间:
root@test 02:01:35:
SELECT * FROM test_order_desc WHERE END_TIME > now() ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
+---------+-----------+------------+------+---------------------+---------------------+
col2...................................................................................
+---------+-----------+------------+------+---------------------+---------------------+
Data1..................................................................................
Data2..................................................................................
+---------+-----------+------------+------+---------------------+---------------------+
12 ROWS IN SET (0.00 sec)
可以看到执行时间已经降到了毫秒以下,查看其执行计划:
root@test 02:01:42:
EXPLAIN SELECT * FROM test_order_desc WHERE END_TIME > now() ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
+----+-------------+----------+-------+-----------------+----------------+---------+------+------+-------------+
| id | select_type | TABLE | TYPE | possible_keys | KEY | key_len | REF | ROWS | Extra |
+----+-------------+----------+-------+-----------------+----------------+---------+------+------+--------
| 1 | SIMPLE | test_order_desc | INDEX | ind_hot_endtime | ind_gmt_create | 14 | NULL | 48 | USING WHERE |
可以看到优化器已经选择了ind_gmt_create索引扫描,这样的话就避免了对结果集进行排序的过程,同时优化器预估扫描14行数据就会得到满足查询条件的数据(END_TIME > now()),执行计划非常的理想。
案例二:
root@127.0.0.1 : test_db 16:05:15:
EXPLAIN SELECT b.*,a.*,k.* FROM instance b LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;
B表的idx_uid_stat_inid的索引列包括了(user_id,status,instance_no):
我们从执行计划上分析来看,表的连接顺序为:b—>r_a—>a—>k,可以看到执行计划的第一行中需要扫描49212行的数据,同时由于status采用的是in的方式,instance_no即使在索引中也用不上,这样就导致了排序使用到了临时表,这也是导致sql执行慢的原因。我们看到sql中的最后一个排序为order by b.instance_no asc limit 37300,50,这里我们好像可以看到优化的曙光,调整数据库的索引以满足B表的排序需求:
root@127.0.0.1 : test_db 16:05:04 ALTER TABLE instance ADD INDEX ind_user_id(user_id,instance_no);
Query OK, 0 ROWS affected (0.56 sec)
调整索引后查看执行计划:
root@127.0.0.1 : test_db 16:09:42
EXPLAIN SELECT b.*,a.*,k.* FROM instance b LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;
我们加上force index强制走我们新加的索引:
root@127.0.0.1 : test_db 16:10:24
EXPLAIN SELECT b.*,a.*,k.* FROM instance b force INDEX (ind_user_id) LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;
可以看到在加上提示符后,使用到了我们新加的索引,扫描的行数为54580行,执行时间:
root@127.0.0.1 : test_db 16:10:30
SELECT b.*,a.*,k.* FROM instance b force INDEX (ind_user_id) LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;
(0.49 sec)
原始的执行时间:
root@127.0.0.1 : test_db 16:10:51:
SELECT b.*,a.*,k.* FROM instance b LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;
(1.28 sec)
总结:
Order by desc/asc limit的优化技术有时候在你无法建立很好索引的时候,往往会得到意想不到的优化效果,但有时候有一定的局限性,优化器可能不会按照你既定的索引路径扫描,优化器需要考虑到查询列的过滤性以及limit的长度,当查询列的选择性非常高的时候,使用sort的成本是不高的,当查询列的选择性很低的时候,那么使用order by +limit的技术是很有效的。
mysql limit asc_MySql sql优化之order by desc/asc limit M-阿里云开发者社区相关推荐
- mysql数据漂移_数据库漂移-和数据库漂移相关的内容-阿里云开发者社区
MySQL双主一致性架构优化 | 架构师之路 一.双主保证高可用 MySQL数据库集群常使用一主多从,主从同步,读写分离的方式来扩充数据库的读性能,保证读库的高可用,但此时写库仍然是单点. 在一个My ...
- mysql 轨迹数据存储_基于Tablestore实现海量运动轨迹数据存储-阿里云开发者社区...
前言 现在越来越多的人都开始关心自己的运动数据,比如每日的计步.跑步里程.骑行里程等.运动APP与运动类的穿戴设备借助传感器.地图.GPS定位等技术,收集好运动数据以后,通过与互联网社交功能结合,产生 ...
- 阿里 postgresql mysql_如何将PostgreSQL与MySQL相结合,实现1+12的组合拳?(下)-阿里云开发者社区...
查看上篇文章,点击这里. (4)无死角全加密 前面讲了一下我们有一个无死角全加密的一个版本,是一个特殊的版本.这个版本也是跟跟达摩院合作输出的一个版本.它能够防网络攻击,数据库攻击,操作系统攻击,存储 ...
- mysql derived2_MySQL · 新特性分析 · 5.7中Derived table变形记-阿里云开发者社区
Derived table实际上是一种特殊的subquery,它位于SQL语句中FROM子句里面,可以看做是一个单独的表.MySQL5.7之前的处理都是对Derived table进行Material ...
- mysql c测试程序_MySQL · 最佳实践 · 一个TPC-C测试工具sqlbench使用-阿里云开发者社区...
TPC-C是数据库系统经常使用的一个性能测试标准,目前开源社区里有几个可以使用的TPC-C测试工具,如BenchmarkSQL.DBT2. tpcc-mysql等.今天这里要介绍的是另一个TPC-C测 ...
- mysql hang住_mysql 5.7不定期的hang住重启-问答-阿里云开发者社区-阿里云
线上一台mysql 5.7.17版本实例,系统centos 6.4 ,96G内存,SSD磁盘,buffer pool 60G,buffer pool instance 8,24 CPU.实例访问情况如 ...
- mysql总是出现-_mysql 总是莫名其妙的关闭:报错
-问答-阿里云开发者社区-阿里云...
CentOS MYSQL 5.6不知道为什么,MYSQL总是莫名其妙的被关闭,然后网页提示 Connect Error (1045)Access denied for user 'root'@'172 ...
- mysql并发插入死锁_MySQL: 并发replace into的死锁问题分析-阿里云开发者社区
测试版本:MySQL5.6.23测试表: create table t1 (a int auto_increment primary key, b int, c int, unique key (b) ...
- mysql第二天无法连接_jdbc 连接mysql 第二天就连接不成功,什么原因?-问答-阿里云开发者社区-阿里云...
情况是这样,我做的是一个SSH项目,中间需要连接另个一个项目数据库查询数据,也算是双数据源,我就建了个DBUtil类 创建 Connection对象,每天重启起来了 第二天早上页面就访问不了了 我怀疑 ...
最新文章
- mysql的worker 线程_MySQL线程
- AndoridSQLite数据库开发基础教程(7)
- python--thread多线程总结
- Cissp-【第5章 身份与访问管理】-2021-3-14(601页-660页)
- 服务器应用程序不可用您试图在此 Web 服务器上访问的 Web 应用程序当前不可用。请点击 Web 浏览器中的“刷...
- 这 4 款实用小工具,能让你的电脑变得好用又骚气
- Oracle 查询历史数据(转帖)
- python矩阵乘法_鱼书——第一章 Python入门
- [转]WF事件驱动(4) -持久化
- 软件工程 c java的联系_软件工程—WC功能实现 (JAVA)
- 张家口zec挖矿软件哪里下载_电脑小白去哪里下载正规软件?
- Spring4-@PostConstruct和@PreDestroy注解的使用
- 计算机应用基础教材提纲,《计算机应用基础》课程教学大纲
- 为 Windows 系统替换优雅的苹果字体
- 项目集锦 | 易基因近期m6A甲基化(MeRIP-seq)研究成果
- Java中 … 三个点是什么意思?
- ipad查看qq邮箱收件服务器,ipad邮件设置qq邮箱
- html5黑色主题登录网页,永恒经典 18个黑白灰配色的网页设计作品
- 手机游戏的分析,设计,思考
- vue3.0移动端 ui_vue.js的移动UI元素
热门文章
- 前端学习(2198):vuex-state单一状态的理解
- 前端学习(1701):前端系列javascript之闭包
- mybatis学习(40):逆向工程的创建
- git 本地推送本地仓库到远程
- python .center用法_Python Pandas Series.str.center()用法及代码示例
- 记腾讯互娱网站布局(1)
- foxitreadersdk 打开远程文件_一种最不为人知最简单最方便的用电脑操作手机上的文件...
- 关刀机器人_小学机器人活动总结
- 关于spring MVC 绑定json字符串与实体类绑定
- VS2010与QT的集成开发环境