位置: 编程技术 - 正文
MySQL索引优化的实际案例分析(mysql索引优化是什么意思)
编辑：rootadmin推荐整理分享MySQL索引优化的实际案例分析(mysql索引优化是什么意思)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:mysql索引优化是什么意思,mysql索引优先级是什么,mysql索引优化的方案,mysql索引优化的几种方式是什么,mysql索引优化的方案,mysql索引优化是什么意思,mysql索引优化的方案,mysql索引优化的方案,内容如对您有帮助，希望把文章链接给更多的朋友！
Order by desc/asc limit M是我在mysql sql优化中经常遇到的一种场景，其优化原理也非常的简单，就是利用索引的有序性，优化器沿着索引的顺序扫描，在扫描到符合条件的M行数据后，停止扫描；看起来非常的简单，但是我经常看到很多性能较差的sql没有利用这个优化规律，下面将结合一些实际的案例来分析说明：
案例一：
一条sql执行非常的慢，执行时间为：
执行计划如下：
Ind_hot_endtime索引为：
在注意到sql中满足过滤条件end_time>now()的有行，在加上剩余的条件中含有order by，这样会造成排序的结果集非常的大，执行非常的耗费资源；于是分析sql，在sql中包括了order by desc limit这样的排序条件后，新增适当的索引满足排序的条件，同时由于有limit的限制结果集，当扫描到满足条件的行数后退出查询，那么我们来看看优化效果：
添加索引：
再次执行sql，观察其执行时间：
可以看到执行时间已经降到了毫秒以下,查看其执行计划：
可以看到优化器已经选择了ind_gmt_create索引扫描，这样的话就避免了对结果集进行排序的过程，同时优化器预估扫描行数据就会得到满足查询条件的数据（END_TIME > now()），执行计划非常的理想。
案例二：
B表的idx_uid_stat_inid的索引列包括了（user_id，status，instance_no）：
我们从执行计划上分析来看，表的连接顺序为：b—>r_a—>a—>k，可以看到执行计划的第一行中需要扫描行的数据,同时由于status采用的是in的方式，instance_no即使在索引中也用不上，这样就导致了排序使用到了临时表,这也是导致sql执行慢的原因。我们看到sql中的最后一个排序为order by b.instance_no asc limit ,，这里我们好像可以看到优化的曙光，调整数据库的索引以满足B表的排序需求：
调整索引后查看执行计划：
我们加上force index强制走我们新加的索引：
可以看到在加上提示符后，使用到了我们新加的索引，扫描的行数为行，执行时间：
原始的执行时间：
总结：Order by desc/asc limit的优化技术有时候在你无法建立很好索引的时候，往往会得到意想不到的优化效果，但有时候有一定的局限性，优化器可能不会按照你既定的索引路径扫描，优化器需要考虑到查询列的过滤性以及limit的长度，当查询列的选择性非常高的时候，使用sort的成本是不高的，当查询列的选择性很低的时候，那么使用order by +limit的技术是很有效的。
浅谈MySQL中的子查询优化技巧 mysql的子查询的优化一直不是很友好，一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一，你可以点击这里，这里来获得一些信息，mysql
MySQL的id关联和索引使用的实际优化案例 昨晚收到客服MM电话，一用户反馈数据库响应非常慢，手机收到load异常报警，登上主机后发现大量sql执行非常慢，有的执行时间超过了s优化点一：SELEC
MySQL在关联复杂情况下所能做出的一些优化 昨天处理了一则复杂关联SQL的优化，这类SQL的优化往往考虑以下四点：第一.查询所返回的结果集，通常查询返回的结果集很少，是有信心进行优化的；
标签: mysql索引优化是什么意思
本文链接地址:https://www.jiuchutong.com/biancheng/347324.html 转载请保留说明！
