SQL怎样优化包含GROUP BY的复杂查询性能？

根本原因是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）。