优化group by
一、问题背景
现网出现慢查询,在500万数量级的情况下,单表查询速度在30多秒,需要对sql进行优化,sql如下:
二、看执行计划
三、优化
说实话,我是不知道该怎么优化的,这玩意还能怎么优化啊!先说下,下面的思路都是没用的。
思路一:
后面应该加上 order by null;避免无用排序,但其实对结果耗时影响不大,还是很慢。思路二:
where条件太复杂,没索引,导致查询慢,但我给where条件的所有字段加上了组合索引,也还是没用思路三:
既然group by慢,换distinct试试??(这里就是本篇博客里说的神奇的地方了)
四、你以为这就结束了吗
我是真的希望就这么结束了,那这个问题就很简单的解决了,顺便还自以为是的发现了一个新知识。但是!这个bug转给测试后,测试一测,居然还是30多秒!?这是什么情况!!???我当然是不信了,去测试电脑上执行sql,还真是30多秒。。。我又回我的电脑上,连接同一个数据库,一执行sql,0.8秒!?什么情况,同一个库,同一个sql,怎么在两台电脑执行的差距这么大!后来直接在服务器上执行:
五、后续(还未解决)
感谢大家出谋划策,我来回复下问题进展:1.所谓的sqlyog查询快,命令行查询慢的现象,已经找到原因了。是因为sqlyog会在查询语句后默认加上limit 1000,所以导致很快。这个问题不再纠结。2.我已经试验过的方法(都没有用):①给app_account字段加索引。②给sql语句后面加order by null。③调整where条件里字段的查询顺序,有索引的放前面。④给所有where条件的字段加组合索引。⑤用子查询的方式,先查where条件里的内容,再去重。测试环境和现网环境数据还是有点不一样的,我贴一张现网执行sql的图(1分钟。。。):
六、最终解决方案
感谢评论里42楼的@言枫大佬!经过你的提醒,我确实发现,explain执行计划里,索引好像并没有用到我创建的idx_end_time。然后果断在现网试了下,强制指定使用idx_end_time索引,结果只要0.19秒!
——End——
鸣谢:
https://www.cnblogs.com/dijia478/p/11550902.html
本文来自博客园,作者:{春光牛牛,yak},转载请注明原文链接:https://www.cnblogs.com/yakniu/p/16358322.html
欢迎各位大佬们评论指正
QQ讨论群:610129902