记一次神奇的 sql 查询经历，group by 慢查询优化！

水深无声 2023-06-12 06:29 21阅读 0赞

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

扫描下方海报 **试读**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

![640?wx\_fmt=png][640_wx_fmt_png]

来源：

https://www.cnblogs.com/dijia478/p/11550902.html

## 一、问题背景 ##

现网出现慢查询，在500万数量级的情况下，单表查询速度在30多秒，需要对sql进行优化，sql如下：

![640?wx\_fmt=png][640_wx_fmt_png 1]

我在测试环境构造了500万条数据，模拟了这个慢查询。

简单来说，就是查询一定条件下，都有哪些用户的。很简单的sql，可以看到，查询耗时为37秒。

说一下app\_account字段的分布情况，随机生成了5000个不同的随机数，然后分布到了这500万条数据里，平均来说，每个app\_account都会有1000个是重复的值，种类共有5000个。

## 二、看执行计划 ##

![640?wx\_fmt=png][640_wx_fmt_png 2]

可以看到，group by字段上我是加了索引的，也用到了。

## 三、优化 ##

说实话，我是不知道该怎么优化的，这玩意还能怎么优化啊！先说下，下面的思路都是没用的。

### 思路一： ###

后面应该加上 order by null；避免无用排序，但其实对结果耗时影响不大，还是很慢。

![640?wx\_fmt=png][640_wx_fmt_png 3]

### 思路二： ###

where条件太复杂，没索引，导致查询慢，但我给where条件的所有字段加上了组合索引，也还是没用

![640?wx\_fmt=png][640_wx_fmt_png 4]

![640?wx\_fmt=png][640_wx_fmt_png 5]

### 思路三： ###

既然group by慢，换distinct试试？？（这里就是本篇博客里说的神奇的地方了）

![640?wx\_fmt=png][640_wx_fmt_png 6]

卧槽？？？！！！这是什么情况，瞬间这么快了？？！！！

虽然知道group by和distinct有很小的性能差距，但是真没想到，差距居然这么大！！！大发现啊！！

## 四、你以为这就结束了吗 ##

我是真的希望就这么结束了，那这个问题就很简单的解决了，顺便还自以为是的发现了一个新知识。

但是！

这个bug转给测试后，测试一测，居然还是30多秒！？这是什么情况！！？？？

我当然是不信了，去测试电脑上执行sql，还真是30多秒。。。

我又回我的电脑上，连接同一个数据库，一执行sql，0.8秒！？

什么情况，同一个库，同一个sql，怎么在两台电脑执行的差距这么大！

后来直接在服务器上执行：

![640?wx\_fmt=png][640_wx_fmt_png 7]

醉了，居然还是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分钟。。。）：

![640?wx\_fmt=png][640_wx_fmt_png 8]

## 六、最终解决方案 ##

感谢评论里42楼的@言枫大佬！

经过你的提醒，我确实发现，explain执行计划里，索引好像并没有用到我创建的idx\_end\_time。

然后果断在现网试了下，强制指定使用idx\_end\_time索引，结果只要0.19秒！

![640?wx\_fmt=png][640_wx_fmt_png 9]

至此问题解决，其实同事昨天也在怀疑，是不是这个表索引建的太多了，导致用的不对，原本用的是idx\_org\_id和idx\_mvno\_id。

现在强制指定idx\_end\_time就ok了！

**最后再对比下改前后的执行计划**

改之前（查询要1分钟左右）：

![640?wx\_fmt=png][640_wx_fmt_png 10]

改之后（查询只要几百毫秒）：

![640?wx\_fmt=png][640_wx_fmt_png 11]

**END**

**如有收获，请划至底部，点击“在看”，谢****谢****！**

![640?wx\_fmt=png][640_wx_fmt_png]

欢迎长按下图关注公众号**石杉的架构笔记**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

**BAT架构经验倾囊相授**

[640_wx_fmt_jpeg]: /images/20230531/7ec29bbb4119411099c31a172d9684b9.png
[640_wx_fmt_jpeg 1]: /images/20230531/79d72ed33a8f471ba542b27ae4b2cf8d.png
[640_wx_fmt_png]: /images/20230531/d9b5ad30b3d64f1c8af06be8e9eb9365.png
[640_wx_fmt_png 1]: /images/20230531/b188f285419948f3b63c0e0642dea2bf.png
[640_wx_fmt_png 2]: /images/20230531/e053da92368c4742b7258d5675a46832.png
[640_wx_fmt_png 3]: /images/20230531/3bc9a97ec577475988ca8f9566e0d53c.png
[640_wx_fmt_png 4]: /images/20230531/90f93e7cb6b64b728a2485122467ae2b.png
[640_wx_fmt_png 5]: /images/20230531/74d9f346f9984fdcbacc7707b0b480cf.png
[640_wx_fmt_png 6]: /images/20230531/3c901493b8524d069145e821d88c43ae.png
[640_wx_fmt_png 7]: /images/20230531/e16213d7a4a54b8fb73ad0986d5cc380.png
[640_wx_fmt_png 8]: /images/20230531/2d14d6571c7a45359c13defad885c452.png
[640_wx_fmt_png 9]: /images/20230531/a6a8114824e842078ae3da50cfb42df4.png
[640_wx_fmt_png 10]: /images/20230531/f6f7394baffc46908cba33bb8e4d9619.png
[640_wx_fmt_png 11]: /images/20230531/68fc07b975ab42669b393cc416075147.png
[640_wx_fmt_jpeg 2]: /images/20230531/9434567ceedd4cbf91503360ce7f7af2.png