MySql sql优化之order by desc/asc limit M

  • 时间:
  • 浏览:0

再次执行sql,观察其执行时间:

还还还都可以 还还还都可以 看完优化器而且取舍了ind_gmt_create索引扫描,那我语句就防止了对结果集进行排序的过程,一同优化器预估扫描14行数据就会得到满足查询条件的数据(END_TIME > now()),执行计划非常的理想。

案例一:

你这一人从执行计划上分析来看,表的连接顺序为:b—>r_a—>a—>k,还还还都可以 还还还都可以 看完执行计划的第一行中前要扫描49212行的数据,一同而且status采用的是in的土方法,instance_no即使在索引中也用不上,那我就是因为着了排序使用到了临时表,这也是是因为着sql执行慢的是因为着。你这一人看完sql中的最后有另一有一个 排序为order by b.instance_no asc limit 37200,200,这里你这一人好像还还还都可以 还还还都可以 看完优化的曙光,调整数据库的索引以满足B表的排序需求:

原始的执行时间:

root@127.0.0.1 : test_db 16:10:51:

Order by desc/asc limit M是我在mysql sql优化中经常 遇到的五种 场景,其优化原理也非常的简单,而且利用索引的有序性,优化器沿着索引的顺序扫描,在扫描到符合条件的M行数据后,停止扫描;看起来非常的简单,而且我经常 看完全都性能较差的sql那么利用你你这一优化规律,下面将结合你这一实际的案例来分析说明:

案例二:

总结:

Order by desc/asc limit的优化技术有前一天在你无法建立很好索引的前一天,往往会得到意想还还还都可以 的优化效果,但有前一天有一定的局限性,优化器而且越多按照你既定的索引路径扫描,优化器前要考虑到查询列的过滤性以及limit的长度,当查询列的取舍性非常高的前一天,使用sort的成本是不高的,当查询列的取舍性很低的前一天,那么使用order by +limit的技术是很有效的。



B表的idx_uid_stat_inid的索引列包括了(user_id,status,instance_no):

还还还都可以 还还还都可以 看完执行时间而且降到了毫秒以下,查看其执行计划:

调整索引后查看执行计划:

还还还都可以 还还还都可以 看完在换成提示符后,使用到了你这一人新加的索引,扫描的行数为545200行,执行时间:

一条sql执行非常的慢,执行时间为:

Ind_hot_endtime索引为:

换成索引:

在注意到sql中满足过滤条件end_time>now()的有113549行,在换成剩余的条件中蕴藏order by,那我会造成排序的结果集非常的大,执行非常的耗费资源;于是分析sql,在sql中包括了order by desc limit那我的排序条件后,新增适当的索引满足排序的条件,一同而且有limit的限制结果集,当扫描到满足条件的行数后退出查询,那么你这一人来看看优化效果:

你这一人换成force index强制走你这一人新加的索引: