Navicat 不直接显示 PostgreSQL HashAgg 细节，需手动执行 EXPLAIN (ANALYZE, BUFFERS, VERBOSE) 查看 Batches、Memory Usage、Group Key 等字段诊断溢出与性能问题。
Navicat 本身不直接显示 PostgreSQL 的 HashAgg 执行细节，必须通过原生 EXPLAIN 输出配合手动解读。 它的“执行计划”视图只做基础可视化，无法展开哈希表批次、内存使用或是否降级为磁盘哈希等关键信息——这些全藏在 EXPLAIN (ANALYZE, BUFFERS, VERBOSE) 的文本输出里。
Navicat 中触发真实执行计划的正确方式
Navicat 的“解释”按钮（⚡ 图标）默认调用的是简版 EXPLAIN，不带 ANALYZE 和 VERBOSE，会漏掉 HashAgg 的实际行为。必须手动改写：
- 在查询编辑器中，把
SELECT ...改成EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT ... - 确保语句末尾没有分号（Navicat 对多语句支持不稳定，分号可能截断输出）
- 执行后，在“结果”标签页查看纯文本输出，不要依赖“图表”视图
识别 HashAgg 节点的关键字段
在 EXPLAIN 文本中，定位到含 HashAggregate 的行，重点看这几项：
-
Batches: 1表示全程在内存完成；若为Batches: 2或更高，说明已溢出到磁盘，性能风险显著上升 -
Memory Usage: 24 kB是当前批次哈希表占用内存，对比你的work_mem设置（如默认 4MB），若接近或超过，就是溢出前兆 -
Group Key: t1.a确认分组字段是否命中索引——如果这里出现函数包裹（如Group Key: upper(t1.name)），索引失效，必然走 HashAgg 且无法优化 - 没有
Sort Key字段，可佐证未走排序聚合（GroupAggregate），而是纯哈希路径
为什么 Navicat 的图形化执行计划会误导你
它的“执行计划”面板把 HashAggregate 和 GroupAggregate 都渲染成相似的“聚合”图标，完全掩盖了底层机制差异。更危险的是：
- 它自动隐藏
Buffers统计，你看不到 shared hit/reads，无法判断是否大量读磁盘 - 不显示
Output字段，无法验证是否因SELECT *导致哈希表存了整行而非仅分组键+聚合值，白白放大内存压力 - 当查询含
LIMIT（如SELECT DISTINCT a FROM t1 LIMIT 10），图形视图可能错误暗示“提前终止”，实际 HashAgg 仍需处理全部输入——文本输出里的actual time和rows才是真相
真正要调优 HashAgg，得盯着 EXPLAIN 文本里那几行原始数据：批次数、内存用量、是否溢出、分组键是否干净。图形界面省事，但省掉的恰恰是最关键的诊断线索。
