前几周我们深入探讨了执行计划分析、索引设计策略、COUNT查询优化以及事务隔离级别等MySQL性能优化核心话题，今天聚焦另一个日常开发中使用频率极高、却最容易踩坑的重难点——GROUP BY分组查询优化。
凌晨1点，报表系统整整卡了半小时无法响应。执行计划中赫然显示着三个危险信号：Using where; Using temporary; Using filesort。这三个关键词同时出现，意味着MySQL不得不在内存中创建一张临时表，将3000万行数据逐条插入，再进行全表扫描排序，最终只返回寥寥10行结果。
这哪里是在执行SQL查询，分明就是在高负荷燃烧CPU资源。
不少开发者觉得“不就是分个组嘛，能有多复杂”，但实际生产环境中的性能瓶颈远比想象中更加棘手。今天就从句柄执行机制入手，把GROUP BY性能相关的各类痛点逐一拆解分析。
首先搞清楚：GROUP BY底层究竟在做什么？
执行一条GROUP BY查询时，数据库内部依次完成了三项核心操作：
- 排序：先将数据按照分组字段进行排序。只有相同值的行彼此相邻，才能正确完成分组统计。
- 分组：接着遍历已排序的结果集，遇到相同值则累加聚合，碰到新值则开启新组。
- （可选）二次排序：如果查询中包含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 + 窗口函数的组合实战运用
在分组后计算占比、同比等复杂业务场景中，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高负荷程序”转变为“毫秒级响应”。面对超大数据量且业务允许误差的场景，采样估算、预计算汇总表以及分区表优化也是值得重点考虑的成熟方案。
