SQL优化案例分享 | 为什么MySQL 5.7以前GROUP BY会排序？如何避免隐式排序？

你是否曾经困惑：为什么相同的GROUP BY语句在不同MySQL版本上性能差异巨大？今天我们揭秘MySQL隐式排序的"黑历史"，助你轻松优化查询性能！

一、隐藏的性能杀手

在MySQL 5.7之前的版本中，存在一个"不为人知"的特性：当你执行GROUP BY查询时，即使没有明确要求排序，结果也会默认按照GROUP BY字段排序。这种看似贴心的行为，实际上可能成为严重的性能瓶颈！

想象一下，你只是想统计各个类别的商品数量，却不知不觉触发了一个耗时的排序操作。尤其是在处理海量数据时，这种隐式排序会让你的查询速度"极速下滑"。

二、为何会有这种设计？

MySQL早期版本的设计思路是：在执行GROUP BY时，引擎需要确保结果的分组是正确的，而排序是实现分组的一种直接方式。因此，分组和排序操作被紧密捆绑在一起。

这种设计带来了两大问题：

1. 性能损耗排序是极其消耗资源的操作，特别是对于大型数据集
2. 行为不可控用户往往不会预料到这种默认行为，导致性能出现"意外"下降

三、MySQL 5.7之后的变化

在MySQL 5.7之后，MySQL优化器开始有所改进，在某些情况下，如果查询结果不需要排序，MySQL会通过避免不必要的排序来提升性能。特别是当查询没有明确的ORDER BY语句时，MySQL 5.7及以后的版本会避免默认进行排序。

这项优化减少了不必要的性能消耗，特别是在GROUP BY字段上没有索引、且没有要求按特定顺序返回结果时。

四、解决之道

如果你仍在使用MySQL 5.7之前的版本，可以尝试以下几种方法避开这个"隐形陷阱"：

使用ORDER BY NULL 通过明确添加ORDER BY NULL，可以告诉MySQL优化器不进行排序。这样，即使在GROUP BY语句中，MySQL也不会对结果进行排序，从而节省性能。

通过明确添加此指令，显式告知MySQL优化器不执行排序：

SELECT category_id, COUNT(*) 
FROM products 
GROUP BY category_id 
ORDER BY NULL;

在这个查询中，GROUP BY仅进行分组而不会自动排序，ORDER BY NULL明确告诉MySQL不进行排序操作。此方法非常有效，尤其是在没有需求对结果进行排序时。

2. 升级到MySQL 5.7或更高版本 如果可能，考虑将MySQL升级到5.7及以后的版本。这些版本已经对GROUP BY的隐式排序进行了优化，能有效减少不必要的排序操作。

3. 使用索引 如果你的GROUP BY字段上有合适的索引，MySQL可能就会避免进行排序，而是直接利用索引来完成分组操作。例如，假设category_id字段上有索引，那么MySQL可能会直接基于索引来执行GROUP BY，而不进行额外的排序操作。

4. 监控SQL执行计划

如果查询计划中出现了 Using filesort，说明查询进行了排序操作，此时可以考虑使用上述方法优化。

5. 使用专业SQL优化工具

使用PawSQL等专用SQL优化工具，它可以从复杂的SQL文本中识别隐藏排序的隐患，并根据数据库的类型和版本，自动决定是否添加order by null.

五、性能对比实例

我们在一个包含500万条记录的表上进行测试，结果令人震惊：

查询方式执行时间普通GROUP BY8.7秒GROUP BY + ORDER BY NULL2.3秒MySQL 8.0下的GROUP BY2.1秒

性能提升近4倍！这就是了解数据库内部机制带来的实际收益。

六、总结

在MySQL 5.7及之前的版本中，GROUP BY操作会自动进行排序，这种行为是因为查询优化器的设计问题。默认排序虽然在某些场景下符合预期，但在处理大数据集时，隐式排序会引起性能瓶颈。为避免这种问题，你可以通过显式使用ORDER BY NULL来告知优化器不进行排序，或者通过升级到MySQL 5.7及更高版本来享受更优化的查询执行。

往期文章精选

1. SQL优化案例分享 | EXISTS 和 COUNT 子查询怎么选？一招提升子查询性能
2. SQL优化案例分享 | PawSQL 近日推出 Lateral Join 重写优化算法
3. SQL优化案例分享 | PawSQL 优化器谓词下推算法实现分析
4. SQL优化案例分享 | 从321秒到0.2秒的性能飞跃 — TPCH查询优化实战
5. 下载破万！国产软件PawSQL Advisor凭何成为开发者心中的 SQL 优化利器？