记一次神奇的SQL查询经历，group by慢查询优化
source link: http://news.51cto.com/art/202002/610211.htm
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
一、问题背景
现网出现慢查询，在500万数量级的情况下，单表查询速度在30多秒，需要对sql进行优化，sql如下：
我在测试环境构造了500万条数据，模拟了这个慢查询。
简单来说，就是查询一定条件下，都有哪些用户的。很简单的sql，可以看到，查询耗时为37秒。
说一下app_account字段的分布情况，随机生成了5000个不同的随机数，然后分布到了这500万条数据里，平均来说，每个app_account都会有1000个是重复的值，种类共有5000个。
二、看执行计划
可以看到，group by字段上我是加了索引的，也用到了。
三、优化
说实话，我是不知道该怎么优化的，这玩意还能怎么优化啊！先说下，下面的思路都是没用的。
思路一：
后面应该加上 order by null；避免无用排序，但其实对结果耗时影响不大，还是很慢。
思路二：
where条件太复杂，没索引，导致查询慢，但我给where条件的所有字段加上了组合索引，也还是没用
思路三：
既然group by慢，换distinct试试？？（这里就是本篇博客里说的神奇的地方了）
卧槽？？？！！！这是什么情况，瞬间这么快了？？！！！
虽然知道group by和distinct有很小的性能差距，但是真没想到，差距居然这么大！！！大发现啊！！
四、你以为这就结束了吗
我是真的希望就这么结束了，那这个问题就很简单的解决了，顺便还自以为是的发现了一个新知识。
但是！
这个bug转给测试后，测试一测，居然还是30多秒！？这是什么情况！！？？？
我当然是不信了，去测试电脑上执行sql，还真是30多秒。。。
我又回我的电脑上，连接同一个数据库，一执行sql，0.8秒！？
什么情况，同一个库，同一个sql，怎么在两台电脑执行的差距这么大！
后来直接在服务器上执行：
醉了，居然还是30多秒。。。。
那看来就是我电脑的问题了。
后来我用多个同事的电脑实验，最后得出的结论是：
是因为我用的SQLyog！
哎，现在发现了，只有用sqlyog执行这个“优化后”的sql会是0.8秒，在navcat和服务器上直接执行，都是30多秒。
那就是sqlyog的问题了，现在也不清楚sqlyog是不是做什么优化了，这个慢查询的问题还在解决中（我觉得问题可能是出在mysql自身的参数上吧）。
这里只是记录下这个坑，sqlyog执行sql速度，和服务器执行sql速度，在有的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秒！
至此问题解决，其实同事昨天也在怀疑，是不是这个表索引建的太多了，导致用的不对，原本用的是idx_org_id和idx_mvno_id。
现在强制指定idx_end_time就ok了！
最后再对比下改前后的执行计划：
改之前（查询要1分钟左右）：
改之后（查询只要几百毫秒）：
Recommend
-
44
还没关注？ 快动动手指！ 聊技术、论职场！ 为IT人打造一个“有温度”的 狸猫技术窝 背景...
-
37
有一张财务流水表，未分库分表，目前的数据量为9555695，分页查询使用到了limit，优化之前的查询耗时16 s 938 ms (execution: 16 s 831 ms, fetching: 107 ms)，按照下文的方式调整SQL后，耗时347 ms (execution: 163 ms, fetching: 184 m...
-
42
来源：简书 作者：Muscleape 原文链接： https://www.jianshu.com/p/0768ebc4e28d 一，前言 证实 参考资料 ...
-
7
前言： 最近在测试环境中点击一个图表展示页面时，半天才得到后台响应的数据进行页面渲染展示，后台的...
-
5
SQL联表去重查询和优化 本文共有6653个字，关键词：sql、
-
2
V2EX › MySQL 今日遇到的神奇的 sql 优化问题 zzfer · 8 小时 24 分钟前 · 602 次点击 ...
-
4
分布式系统较为复杂，无论写入还是查询，都需要多个节点的配合才能完成操作。本教程以一个分布式 SQL 查询为例，介绍 DolphinDB 分布式数据库的数据流以及其中经历的各类线程池。通过了解 SQL 查询的全过程，也可以帮助我们更好地优化 DolpinDB 的配置和性能。
-
5
从上至下优化 看过一篇文章，印象深刻，里面将数据库查询优化分为四个大的方向 使用钞能力——给DB服务器加物理配置，内存啊，CPU啊，硬盘啊，全上顶配 替换存储系统——根据实际的业务情...
-
4
一条线上慢查询 sql 的原因分析及优化建议 精选 原创 Defonds 2022-11-16 16:24:46
-
5
日常工作中，sql语句执行效率经常成为程序的性能瓶颈，如何快速的执行数据库的增删改查则是一个合格的后端程序员必备技能，本文描述了从发现执行慢的sql到如何优化增删改查的sql语句，以及从架构本身优化查询速度的一些方向，本文是我个人的经验之谈，不一定完全正确...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK