group by 性能优化核心是索引覆盖、前置过滤、避免高基数分组及合理选型；需为分组字段建顺序一致的复合索引，where 条件字段前置，禁用函数分组，优先过滤再分组，必要时用预聚合或 olap 引擎。
GROUP BY 是 SQL 中最常引发性能问题的操作之一，尤其在大数据量、多字段分组或未合理利用索引时，查询可能从毫秒级飙升至分钟级。核心原因在于：数据库需先对数据排序或哈希分组，再聚合计算，这个过程极易成为 I/O 和 CPU 瓶颈。
确保分组字段上有有效索引
索引是优化 GROUP BY 最直接有效的手段。理想情况下，索引应覆盖所有 GROUP BY 字段（顺序一致），并尽量包含 SELECT 中的聚合字段（形成覆盖索引，避免回表）。
- 例如：
SELECT dept_id, COUNT(*) FROM emp GROUP BY dept_id;，应在(dept_id)上建索引；若还查AVG(salary)，则建议建(dept_id, salary)复合索引。 - 注意：WHERE 条件字段也应前置到索引中，如
WHERE status = 'active' GROUP BY dept_id，索引宜为(status, dept_id)，让过滤和分组一步完成。 - 避免在分组字段上使用函数或表达式（如
GROUP BY YEAR(create_time)），这会让索引失效；可改用范围条件 + 预计算列或分区表替代。
减少分组前的数据量
GROUP BY 的开销与输入行数强相关。在分组前尽可能通过 WHERE 过滤、LIMIT（如仅需 TopN 分组）、或提前聚合（子查询/CTE）缩小数据集。
- 写法对比：先过滤再分组（高效）
SELECT city, COUNT(*) FROM user WHERE reg_date >= '2024-01-01' GROUP BY city;vs 先分组后过滤（低效）SELECT city, cnt FROM (SELECT city, COUNT(*) cnt FROM user GROUP BY city) t WHERE cnt > 100; - 对超大数据表，可考虑按时间/区域等维度做预聚合表（如每日统计汇总），把 GROUP BY 从实时查询转为简单读取。
慎用多字段分组与高基数列
分组字段越多、唯一值越多（高基数），分组桶数量越大，内存占用和计算成本越高。特别是对 UUID、手机号、长文本等字段分组，极易触发磁盘临时表（tmp_table_size / max_heap_table_size 不足时）。
- 检查执行计划：若
Extra列出现Using temporary; Using filesort，说明 MySQL 不得不用磁盘临时表完成分组，必须优化。 - 避免直接对高基数字段分组，可先归类降维（如将 IP 转为地区，邮箱转为域名），或改用近似算法（HyperLogLog 估算去重数）。
- PostgreSQL 用户可关注
work_mem设置；MySQL 用户需调优tmp_table_size和max_heap_table_size，但不能无限制增大，应优先从逻辑上精简数据。
选择合适引擎与聚合策略
不同数据库对 GROUP BY 的实现差异较大，需结合场景选型：
- MySQL 8.0+ 支持
GROUP BY ... WITH ROLLUP和哈希分组（当optimizer_switch='hash_group_by=on'），对无序分组更友好；开启前确认是否影响排序需求。 - ClickHouse、Doris 等 OLAP 引擎原生支持向量化 GROUP BY，千万级以上分组速度远超传统关系库，适合报表类场景。
- 若只是求 TOP-N 分组结果（如销量前 10 的商品），可用
LIMIT配合窗口函数或ORDER BY ... LIMIT，避免全量分组后再排序截断。
