mysql中group by执行计划出现using temporary和using filesort即表明未走索引分组，根本原因是索引缺失或结构不匹配；应按等值where条件→group by字段顺序建联合索引，避免函数、类型转换等破坏索引有序性。
MySQL里用EXPLAIN看GROUP BY执行计划
直接在 SELECT 前加 EXPLAIN 就能看，但要注意 GROUP BY 的执行方式取决于是否有合适索引。没索引时 MySQL 往往走 Using temporary; Using filesort，这是性能杀手。
常见错误现象：查询变慢、CPU 占用高、临时表写入磁盘频繁。
- 确保
GROUP BY字段和WHERE条件字段一起建联合索引，顺序按「等值条件 → GROUP BY 字段」排列，比如WHERE status = ? GROUP BY user_id，索引应为(status, user_id) - 避免在
GROUP BY中使用函数或表达式，如GROUP BY YEAR(created_at)会强制全表扫描 + 临时表 -
EXPLAIN结果中若出现Using temporary，基本说明没走索引分组；Using filesort则意味着排序也未下推到索引
PostgreSQL中用EXPLAIN ANALYZE观察实际分组行为
PostgreSQL 不像 MySQL 那样依赖索引做分组优化，它更倾向用 HashAggregate 或 GroupAggregate，具体选哪个看数据量和是否已排序。
使用场景：大表聚合、窗口函数嵌套 GROUP BY、带 HAVING 过滤的复杂分组。
- 运行
EXPLAIN ANALYZE而不只是EXPLAIN，才能看到真实执行时间、内存使用和实际行数（actual rows） - 关注
Group Key是否匹配索引前缀；如果Sort节点出现在GroupAggregate前，说明数据没按 GROUP BY 字段物理有序，得额外排序 - HashAggregate 内存不足时会落盘（
disk: NMB），此时要调大work_mem，但别设太高以防并发多时 OOM
SQL Server里看GROUP BY是否触发Stream Aggregate
Stream Aggregate 是最轻量的分组方式，前提是输入数据已按 GROUP BY 字段排序——这通常靠索引或上游 Sort 算子保证。一旦看到 Hash Match(Aggregate)，就得警惕内存压力和 spill。
容易踩的坑：明明建了索引，执行计划却还是 Hash Match，原因常是 WHERE 条件过滤后结果集太小，优化器觉得排序成本高于哈希。
- 用
SET STATISTICS XML ON获取详细执行计划，搜索Stream Aggregate或Hash Match节点 - 检查索引是否覆盖全部
GROUP BY字段且顺序一致；若含ORDER BY，需确认是否与 GROUP BY 字段相同，否则可能多一个 Sort - 避免在 GROUP BY 列上用
COLLATE或类型转换，会导致索引失效，强制 Hash Match
Oracle中注意GROUP BY和索引访问路径的匹配
Oracle 的 GROUP BY 能否走索引快速分组，关键看执行计划里有没有 INDEX RANGE SCAN 或 INDEX FAST FULL SCAN 后直接接 SORT GROUP BY NOSORT。出现 SORT GROUP BY 就意味着额外排序开销。
性能影响明显：NOSORT 比 SORT 快一个数量级，尤其在千万级表上。
- 用
EXPLAIN PLAN FOR+SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY)查看，重点找NOSORT关键字 - 索引必须包含所有
GROUP BY列，且不能有非前导列的WHERE条件打断索引访问路径（例如索引是(a,b,c)，但查询是WHERE b = ? GROUP BY a,c，就无法利用该索引做 NOSORT） - 统计信息过期会导致优化器误判，执行
DBMS_STATS.GATHER_TABLE_STATS更新后再看执行计划
GROUP BY 执行计划不是只看有没有索引，而是看数据流是否真正免排序、免临时结构。不同数据库对“有序输入”的依赖程度差异很大，同一语句在 MySQL 和 PostgreSQL 里可能走完全不同的路径。别只盯着 EXPLAIN 输出的“type”或“Node”，得结合实际数据分布和索引定义交叉验证。
