GROUP BY 慢的主因是未走索引导致 Using temporary 和 Using filesort；应建联合索引（WHERE等值字段前置+GROUP BY字段居中），优先用 WHERE 而非 HAVING 过滤，大数据量时可用汇总表预计算。
GROUP BY 为什么慢？先看执行计划里的 Using filesort 和 Using temporary
MySQL 在执行 GROUP BY 时，如果无法利用索引完成分组，就会创建临时表 + 排序，这两项在 EXPLAIN 输出里表现为 Using temporary 和 Using filesort —— 这是性能拐点。不是数据量大才慢，而是没走对索引路径就容易触发。
常见诱因包括：
-
GROUP BY字段未建索引，或索引顺序与查询不匹配（比如索引是(a, b)，但写的是GROUP BY b） - SELECT 中包含非分组字段且未用聚合函数包裹（如
SELECT name, COUNT(*) FROM t GROUP BY dept），MySQL 5.7+ 严格模式下直接报错，老版本则可能返回不确定值并强制临时表 - WHERE 条件过滤后仍需扫描大量行，而索引无法同时覆盖过滤和分组
让 GROUP BY 走索引：联合索引设计要点
核心原则：把 GROUP BY 字段放在联合索引最左侧，并尽可能把 WHERE 等值条件字段前置，再接分组字段。MySQL 可以复用同一索引完成过滤 + 分组 + 排序。
例如查询：SELECT dept, COUNT(*) FROM user WHERE status = 1 GROUP BY dept
最优索引是：INDEX(status, dept) —— 注意不是 (dept, status)。因为 status = 1 是等值条件，放前面才能让索引“截断”出一个连续区间，再在这个区间内按 dept 自然有序分组。
如果还有排序需求（如 ORDER BY dept DESC），该索引依然有效；但如果写成 ORDER BY create_time，就又会触发 Using filesort。
HAVING 比 WHERE 更耗？别在 HAVING 里做本该 WHERE 干的事
HAVING 是在分组后过滤，意味着 MySQL 必须先完成全部分组计算（可能涉及临时表和聚合），再丢弃不满足条件的组。而 WHERE 是在分组前过滤，能大幅减少输入行数。
错误写法：SELECT dept, COUNT(*) FROM user GROUP BY dept HAVING dept IN ('tech', 'hr')
正确写法：SELECT dept, COUNT(*) FROM user WHERE dept IN ('tech', 'hr') GROUP BY dept
其他典型陷阱：
- 用
HAVING COUNT(*) > 10筛大组——无法避免全分组，但至少确保WHERE已尽可能缩小范围 - 在
HAVING中引用未出现在SELECT或GROUP BY中的字段（如HAVING salary > 5000），这会导致无法使用索引，且语义模糊
数据量大时，考虑物化中间结果：用汇总表替代实时 GROUP BY
当单表超千万、且 GROUP BY 查询频繁（比如后台报表每分钟刷一次），即使加了索引，I/O 和 CPU 压力仍可能陡增。这时实时聚合就成了瓶颈点。
可行方案：
- 建立轻量级汇总表，按小时/天粒度预计算：
CREATE TABLE user_dept_daily AS SELECT dept, DATE(create_time) d, COUNT(*) c FROM user GROUP BY dept, DATE(create_time)，再配合定时任务增量更新 - 用
INSERT ... SELECT替代复杂GROUP BY，避免长事务锁表；汇总表主键设为(dept, d)，查询时走主键即可 - 若业务允许轻微延迟（如报表容忍 5 分钟），可搭配
EVENT或外部调度器刷新，彻底避开高开销查询
临时表、CTE、窗口函数看起来更“现代”，但在 MySQL 8.0 之前它们并不减少基础分组成本；真正省资源的，永远是少算，而不是换种方式算。
