SQL报表中GROUP BY执行慢的核心原因是缺少索引、数据量大、聚合字段未覆盖及排序分组不协同；优化需建匹配顺序的联合索引、优先WHERE过滤、避免SELECT*、用覆盖索引、慎用DISTINCT与复杂嵌套，并通过EXPLAIN确认是否出现Using temporary或filesort。
SQL报表中 GROUP BY 语句执行慢，核心原因往往不是分组逻辑本身，而是缺少有效索引、数据量大、聚合字段未覆盖、或排序与分组不协同。优化关键在于让数据库尽量用索引完成分组和排序，避免临时表和文件排序。
确保 GROUP BY 字段上有合适索引
数据库在执行 GROUP BY 时，如果能利用索引的有序性，就无需额外排序或建临时表。索引字段顺序需匹配 GROUP BY 子句顺序（最左前缀原则）。
- 例如：
SELECT dept, COUNT(*) FROM emp GROUP BY dept, role;，应建联合索引(dept, role)，而非仅(dept)或(role) - 若后续还带
ORDER BY dept, role，该索引同样可复用，避免二次排序 - 注意：含函数或表达式的
GROUP BY（如GROUP BY YEAR(create_time)）无法直接走普通索引，可考虑生成列+索引或冗余时间维度字段
减少参与分组的数据量
在 GROUP BY 前尽早过滤，比在分组后用 HAVING 筛选更高效。
- 把条件写在
WHERE而非HAVING中：例如统计「2024年活跃部门」，用WHERE create_time >= '2024-01-01'，而不是HAVING MIN(create_time) >= '2024-01-01' - 对大表做分页聚合时，避免全量分组后再
LIMIT；可先用子查询/CTE限制主键范围，再关联聚合 - 考虑分区表：按时间或业务维度分区后，
GROUP BY可能只扫描必要分区，显著降低 I/O
避免 SELECT * 和多余字段干扰索引覆盖
如果 SELECT 列太多，即使 GROUP BY 字段有索引，也可能因回表或无法索引覆盖而变慢。
- 只查真正需要的字段，尤其是避免
SELECT *在聚合语句中出现 - 对高频聚合查询，可建覆盖索引：例如
SELECT dept, status, COUNT(*), AVG(salary) FROM emp WHERE ... GROUP BY dept, status，索引设为(dept, status, salary)（salary放最后，供AVG使用；dept, status满足分组） - 注意：
COUNT(*)不依赖具体列，但COUNT(col)会忽略 NULL，影响是否能走索引，优先用COUNT(*)并确保行存在
慎用 DISTINCT + GROUP BY 或复杂窗口函数嵌套
这类写法容易触发多重临时表，大幅增加内存和 CPU 开销。
- 检查执行计划（
EXPLAIN），确认是否出现Using temporary; Using filesort—— 这是性能瓶颈的明确信号 - 用
GROUP_CONCAT(DISTINCT ...)替代先DISTINCT再GROUP BY的子查询 - 聚合逻辑过于复杂时，考虑拆成中间临时表或物化视图（MySQL 8.0+ 支持不可更新视图，部分场景可用汇总表定时预计算）
