根本原因是mysql未走索引导致using temporary或using filesort，或数据量过大被迫写磁盘临时表；需通过explain确认type、key_len、extra等指标，建立最左前缀匹配的覆盖复合索引，并配合where提前过滤、order by null、预聚合等优化手段。
为什么GROUP BY查询会突然变慢？
根本原因就两个：MySQL没走索引，硬扛排序和分组；或者数据量太大，被迫写磁盘临时表。只要执行计划里出现 Using temporary 或 Using filesort，基本就是卡点所在。不是数据量大才慢，百万级表一有这两个提示，查询就可能从几毫秒跳到几秒甚至更久。
EXPLAIN里看到Using temporary怎么办？
这说明MySQL正在用磁盘临时表做分组，I/O直接拖垮性能。优先检查三件事：
-
type是ALL或index？说明没走有效索引，得重建复合索引 -
key_len是否合理？比如字段是VARCHAR(255)，但只用了前10个字节，key_len却显示765，说明索引定义和实际查询不匹配 -
Extra里有没有Using where？如果没有，WHERE条件很可能没进索引，过滤动作被挪到了分组后
实操建议：先跑 EXPLAIN FORMAT=TRADITIONAL SELECT ... GROUP BY ...，确认问题再动手建索引，别凭感觉加。
GROUP BY字段该建什么索引？
单列索引对多字段分组几乎无效。真正起效的是最左前缀匹配的联合索引，且顺序必须和 GROUP BY 子句完全一致。例如：
GROUP BY user_id, status → 建 INDEX idx_group (user_id, status)
如果还有 WHERE status = 'active'，那应该把过滤性强的字段放前面：INDEX idx_where_group (status, user_id)。覆盖索引更进一步：如果查询还带 COUNT(*) 和 AVG(salary)，索引可扩展为 (status, user_id, salary)，避免回表。
切记：在分组字段上用函数（如 GROUP BY DATE(created_at)）会让整个索引失效——改用冗余日期字段或范围查询替代。
除了索引还能做什么？
索引解决不了全部问题。以下操作常被忽略但效果明显：
- 把
WHERE条件尽量往前推——先过滤再分组，而不是分组完再HAVING过滤 - 不需要排序结果时，显式加上
ORDER BY NULL，省掉默认的隐式排序开销 - 查完立刻要 LIMIT？把它放在外层，但注意
LIMIT不能减少分组计算量，得配合子查询提前截断 - 高频聚合场景（比如日报统计），宁可用定时任务写预聚合表，也别让每次查询都重算
临时表参数（tmp_table_size、max_heap_table_size）调大能缓解磁盘落表，但治标不治本；真正难啃的是高基数字段分组（如 GROUP BY email），这种场景要么降维（提取域名）、要么换引擎（ClickHouse/StarRocks）。
