怎么会执行sql 懒加载 没用_太神奇的 SQL 查询经历,group by 慢查询优化!
作者:dijia478
来源:https://www.cnblogs.com/dijia478/p/11550902.html
一、问题背景
我在测试环境构造了500万条数据,模拟了这个慢查询。简单来说,就是查询一定条件下,都有哪些用户的。很简单的sql,可以看到,查询耗时为37秒。说一下app_account字段的分布情况,随机生成了5000个不同的随机数,然后分布到了这500万条数据里,平均来说,每个app_account都会有1000个是重复的值,种类共有5000个。
二、看执行计划
可以看到,group by字段上我是加了索引的,也用到了。
三、优化
思路一:
后面应该加上 order by null;避免无用排序,但其实对结果耗时影响不大,还是很慢。
思路二:
where条件太复杂,没索引,导致查询慢,但我给where条件的所有字段加上了组合索引,也还是没用。搜索并关注微信公众号码匠笔记回复面试,获取经典面试资料汇总。

思路三:
既然group by慢,换distinct试试??(这里就是本篇博客里说的神奇的地方了)
卧槽???!!!这是什么情况,瞬间这么快了??!!!虽然知道group by和distinct有很小的性能差距,但是真没想到,差距居然这么大!!!大发现啊!!
四、你以为这就结束了吗
醉了,居然还是30多秒。。。。那看来就是我电脑的问题了。后来我用多个同事的电脑实验,最后得出的结论是:是因为我用的SQLyog!哎,现在发现了,只有用sqlyog执行这个“优化后”的sql会是0.8秒,在navcat和服务器上直接执行,都是30多秒。那就是sqlyog的问题了,现在也不清楚sqlyog是不是做什么优化了,这个慢查询的问题还在解决中(我觉得问题可能是出在mysql自身的参数上吧)。这里只是记录下这个坑,sqlyog执行sql速度,和服务器执行sql速度,在有的sql中差异巨大,并不可靠。搜索并关注微信公众号码匠笔记回复面试,获取经典面试资料汇总。
五、后续(还未解决)

六、最终解决方案
至此问题解决,其实同事昨天也在怀疑,是不是这个表索引建的太多了,导致用的不对,原本用的是idx_org_id和idx_mvno_id。现在强制指定idx_end_time就ok了!最后再对比下改前后的执行计划改之前(查询要1分钟左右):
改之后(查询只要几百毫秒):
特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:



长按订阅更多精彩▼

如有收获,点个在看,诚挚感谢
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场,不承担相关法律责任。如若转载,请注明出处。 如若内容造成侵权/违法违规/事实不符,请点击【内容举报】进行投诉反馈!
