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

  • 时间:
  • 浏览:0

案例一:

换成索引:

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

总结:

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

在注意到sql中满足过滤条件end_time>now()的有113549行,在换成剩余的条件暗含有order by,曾经会造成排序的结果集非常的大,执行非常的耗费资源;于是分析sql,在sql中包括了order by desc limit曾经的排序条件后,新增适当的索引满足排序的条件,一起随后有limit的限制结果集,当扫描到满足条件的行数后退出查询,没法当.我歌词 歌词 歌词 来看看优化效果:

可不时要就看优化器随后取舍了ind_gmt_create索引扫描,曾经一段话就处置了对结果集进行排序的过程,一起优化器预估扫描14行数据就会得到满足查询条件的数据(END_TIME > now()),执行计划非常的理想。

Order by desc/asc limit M是我在mysql sql优化中总爱遇到的三种生活场景,其优化原理也非常的简单,太多太多我利用索引的有序性,优化器沿着索引的顺序扫描,在扫描到符合条件的M行数据后,停止扫描;看起来非常的简单,因此 我总爱就看太多太多性能较差的sql没法利用三种优化规律,下面将结合太多太多实际的案例来分析说明:

Ind_hot_endtime索引为:

当.我歌词 歌词 歌词 换成force index强制走当.我歌词 歌词 歌词 新加的索引:



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

可不时要就看执行时间随后降到了毫秒以下,查看其执行计划:

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

案例二:

当.我歌词 歌词 歌词 从执行计划上分析来看,表的连接顺序为:b—>r_a—>a—>k,可不时要就看执行计划的第一行中时要扫描49212行的数据,一起随后status采用的是in的最好的方式,instance_no即使在索引中也用不上,曾经就导致 了排序使用到了临时表,这也是导致 sql执行慢的导致 。当.我歌词 歌词 歌词 就看sql中的最后有另另另另一个排序为order by b.instance_no asc limit 37200,200,这里当.我歌词 歌词 歌词 好像可不时要就看优化的曙光,调整数据库的索引以满足B表的排序需求:

一根绳子 sql执行非常的慢,执行时间为:

可不时要就看在换成提示符后,使用到了当.我歌词 歌词 歌词 新加的索引,扫描的行数为545200行,执行时间:

原始的执行时间:

root@127.0.0.1 : test_db 16:10:51: