PostgreSQL未走HashAggregate通常因优化器判断GroupAggregate更优或哈希不可用：数据已有序（索引支持）、work_mem过低预估溢出、ORDER BY与GROUP BY一致需有序输出、并行限制或含不可哈希类型/聚合函数等硬性排除条件。
PostgreSQL 在执行 GROUP BY 时没走哈希聚合（HashAggregate），通常不是“选错了”，而是优化器判断：流式分组（GroupAggregate）更优，或哈希聚合根本不可用——比如内存预估不足、数据已有序、或并行计划压制了哈希路径。
为什么执行计划里看不到 HashAggregate 节点
常见原因不是配置错误，而是优化器主动绕开了哈希聚合：
-
GROUP BY列上有可用索引，且扫描顺序天然满足分组顺序 → 直接走GroupAggregate（流式分组），省去哈希建表开销 -
work_mem设置过低，优化器预估哈希表会 spill → 主动降级为Sort + GroupAggregate，避免磁盘落盘风险 - 查询含
ORDER BY且与GROUP BY列一致 → 流式分组可一并输出有序结果，哈希聚合还得额外排序 - 启用了并行查询，但哈希聚合在某些版本中对并行支持有限（尤其含复杂聚合函数时），优化器退回串行
GroupAggregate
如何确认是不是真“该用却没用”
别只盯节点名，重点看执行计划里的信号：
- 鼠标悬停
GroupAggregate节点，若显示Strategy: Sorted，说明它正依赖输入有序性工作 - 检查
EXPLAIN (ANALYZE, BUFFERS)输出中Sort节点是否出现；如果没 Sort 却有 GroupAggregate，基本就是索引提供了天然排序 - 对比
HashAggregate和GroupAggregate的Actual Total Time：有时哈希聚合预分配内存慢，流式反而更快 - 临时调高
work_mem（如SET work_mem = '64MB'）再EXPLAIN，若此时出现HashAggregate，说明原值确实卡住了决策
什么情况下哈希聚合一定不会被选
这些硬限制会让优化器直接排除哈希路径：
-
GROUP BY表达式含不可哈希类型，比如jsonb、array、record—— PostgreSQL 9.6+ 对部分类型加了哈希支持，但jsonb的哈希函数默认禁用（需enable_hashagg = on且类型支持） - 聚合函数本身不支持哈希路径，例如
string_agg(DISTINCT ...)或含FILTER子句的窗口嵌套聚合 - 查询含
LIMIT且优化器估算分组后行数极少（如GROUP BY status LIMIT 10），流式分组能提前终止，哈希必须全量处理 - 统计信息严重过期，优化器误判分组键基数极低（比如估算只有 5 个分组，实际有 50 万），认为排序更便宜
真正难调的不是“怎么强制用哈希聚合”，而是“为什么明明数据无序、也没索引，它还不用哈希”——这时候得查 pg_stat_progress_hash 是否被禁用，或确认是否触发了哈希聚合的隐式开关限制，比如 hashagg_table_size 被设得太小。
