GROUP BY优化全解：既不丢数据又快的分组查询

前几周聊了执行计划、索引设计、COUNT优化、事务隔离级别，今天轮到另一个日常开发高频、但也是最容易翻车的话题：GROUP BY。

凌晨1点，报表系统卡了半小时。执行计划里赫然写着：Using where; Using temporary; Using filesort。这三个词凑在一起，意味着MySQL在内存里建了张临时表，把3000万行数据一行行插进去，然后全表扫描排序，最后只返回10行。

这哪是SQL，分明就是在烤CPU。

很多人觉得“不就分个组嘛”，但实际情况比想象中复杂得多。今天就从执行机制说起，把GROUP BY性能相关的坑逐一拆开讲。

先搞清楚：GROUP BY到底在做什么？

执行一条GROUP BY查询时，数据库干了三件事：

1. 排序：先把数据按分组字段排好。只有相同值的行挨在一起，才能分组统计。
2. 分组：然后遍历排序后的结果，遇到相同值就累加，碰到新值就开新组。
3. （可选）再排序：如果还有ORDER BY，再来一轮。

问题就出在第一步——排序。如果分组字段上没有合适的索引，MySQL没法按顺序遍历数据，只能建一张临时表，把符合条件的行全插进去，对临时表做filesort，再遍历分组。3000万行数据，写临时表、全表排序、再遍历——每一步都在烧CPU和磁盘I/O。

Using temporary和Using filesort什么时候触发？

触发Using temporary的规则：GROUP BY的列如果没有可用索引，MySQL必须先排序再分组，排序需要空间，于是建临时表。

但“可用索引”的门槛比想象中高——不是有索引就行，索引列的顺序才是关键。比如order_time有索引但city没有，执行SELECT city, COUNT(*) FROM orders WHERE order_time >= '2026-04-01' GROUP BY city，虽然order_time能过滤数据，但过滤后的数据按city分组时，city没有索引，仍然会触发临时表。

触发Using filesort的规则：当GROUP BY的结果需要排序（比如ORDER BY cnt DESC），且排序无法利用索引完成时，就会触发filesort。

索引优化的核心原则

GROUP BY优化的根本思路是让分组字段走索引，避免临时表和文件排序。

原则一：GROUP BY列必须形成索引的最左前缀

MySQL使用索引进行GROUP BY时，分组列必须是某个索引的最左前缀。如果表上有索引(c1, c2, c3)，GROUP BY c1, c2可以利用索引，但GROUP BY c2, c3不行——因为c2不是最左前缀。

原则二：索引顺序决定一切——WHERE条件中的范围查询是分水岭

当WHERE条件中包含范围查询（>、<、BETWEEN）时，索引的使用会受到限制。如果WHERE中有范围条件，范围条件涉及的列必须放在索引的后面，GROUP BY列必须前置。

举例：查询“2026年4月之后的订单，按城市分组统计订单数”：

SELECT city, COUNT(*) 
FROM orders 
WHERE order_time >= '2026-04-01' 
GROUP BY city;

推荐索引：(city, order_time) —— GROUP BY列city在前，范围条件order_time在后。

如果把索引建为(order_time, city)，虽然order_time能过滤数据，但过滤后的数据按city分组时，city不在索引的前缀位置，依然会触发临时表。

原则三：覆盖索引进一步提速

如果索引不仅包含GROUP BY列，还包含聚合函数需要的列，查询可以直接从索引返回结果，不需要回表。例如SELECT city, SUM(amount) FROM orders GROUP BY city，索引(city, amount)可以让MySQL直接从索引完成分组和聚合。

MySQL 8.0的两大优化

优化一：取消GROUP BY的隐式排序

在MySQL 5.7及之前，GROUP BY默认会按分组字段排序。如果不需要排序结果，可以添加ORDER BY NULL来消除排序开销。

MySQL 8.0取消了GROUP BY的隐式排序。如果确实需要排序，必须显式写ORDER BY。这避免了不必要的排序开销，是一个值得关注的性能优化点。

优化二：Loose Index Scan（松散索引扫描）

这是MySQL使用索引处理GROUP BY的最高效方式。当GROUP BY列是索引的最左前缀时，MySQL可以“松散地”扫描索引，跳过不属于当前组的数据，只读取每个组的第一个键值。

举例：表有索引(c1, c2, c3)，查询GROUP BY c1, c2，Loose Index Scan只需要读取每个(c1, c2)组合的第一行，而不是扫描所有行。当没有WHERE条件时，扫描的行数等于分组数，远小于总行数。

大数据量下的近似分组

当数据量极大且业务允许误差时，可以考虑近似分组方案：

• 采样估算：对数据进行抽样（如WHERE id % 100 = 0），在样本上做GROUP BY，再按比例放大结果。适用于趋势分析、快速报表。
• 预计算汇总表：对于固定维度的分组统计（如每日、每小时的聚合），可以定时计算并存入汇总表，查询直接读汇总表。
• 分区表优化：在大数据量场景下，结合分区表设计可以进一步减少数据扫描范围。

GROUP BY + 窗口函数的组合运用

分组后计算占比、同比等场景，GROUP BY和窗口函数可以组合使用：

-- 计算每个城市订单数占总订单数的比例
SELECT city, 
       COUNT(*) AS city_cnt,
       COUNT(*) / SUM(COUNT(*)) OVER () AS ratio
FROM orders
GROUP BY city;

窗口函数在分组后的结果集上计算，不需要二次聚合，比子查询写法更简洁高效。

总结

GROUP BY的性能问题，根源往往在索引设计。理解临时表和文件排序的触发条件，遵循“GROUP BY列前置、范围条件后置、覆盖索引收尾”的索引设计原则，再配合MySQL 8.0的Loose Index Scan和取消隐式排序等新特性，就能让分组查询从“CPU烤机程序”变成“秒级响应”。遇到大数据量且业务允许误差时，采样估算和预计算也是值得考虑的方案。