PostgreSQL默认对多字段GROUP BY倾向选择GroupAggregate，因其假设字段组合具排序局部性而先排序再分组；但若字段无序或高基数，Sort阶段耗时剧增，此时HashAggregate可跳过排序更高效。
为什么GROUP BY多字段容易触发GroupAggregate而不是HashAggregate
PostgreSQL默认在多字段GROUP BY时倾向用GroupAggregate，因为它假设字段组合有较强排序局部性，会先走Sort再分组。但实际中，如果字段间无序或高基数，排序开销远超哈希构建成本——这时GroupAggregate的actual time里常看到明显Sort阶段耗时，而HashAggregate能直接跳过这步。
-
EXPLAIN ANALYZE里出现Sort节点且ExecutionTime中占比超40%，基本可判定是排序拖慢了聚合 - MySQL不显式区分
HashAggregate和GroupAggregate，但type=ALL扫描+Using temporary; Using filesort提示同样意味着排序瓶颈 - 字段顺序影响大：
GROUP BY a, b若a低基数、b高基数，比反过来更易触发哈希；优化器对前导字段选择敏感
强制HashAggregate的实操手段（PostgreSQL）
不能只靠enable_sort=off——它禁用的是独立Sort节点，不影响GroupAggregate内部排序逻辑。真正有效的是让优化器“觉得”哈希更划算：
- 给
GROUP BY字段建联合索引，但**不带ORDER BY**：CREATE INDEX idx_multi ON t(a, b, c)。索引存在本身会提升统计信息精度，促使优化器重估哈希收益 - 手动注入多列统计：
ANALYZE t (a, b, c)。PostgreSQL 12+支持此语法，能显著提升优化器对组合字段唯一值数（ndistinct）的估算准确度 - 用
/*+ HashAggregate(t) */提示（需启用pg_hint_plan），比Leading()更直接；但注意该提示仅对当前查询生效，不可全局覆盖
MySQL下等效的哈希分组替代方案
MySQL没有HashAggregate概念，但可通过写法绕过隐式排序，逼近同等效果：
- 加
ORDER BY NULL显式关闭排序：GROUP BY a, b ORDER BY NULL。这是最轻量级干预，适用于确认不需要结果有序的报表场景 - 用
STRAIGHT_JOIN控制驱动表，确保GROUP BY字段全来自小表或索引覆盖表，避免大表被拉入内存排序 - 对超大数据集，拆成两层：先
SELECT DISTINCT a, b FROM t WHERE ...（走覆盖索引），再用结果集JOIN回原表聚合，把哈希压力从引擎转移到应用层
最容易被忽略的陷阱：统计信息陈旧与字段相关性
即使建了联合索引、加了ANALYZE，如果字段间存在强相关（比如user_id和tenant_id总是成对出现），优化器仍可能低估组合唯一值数量，继续选GroupAggregate。这时候必须人工干预：
查真实唯一组合数：SELECT COUNT(*) FROM (SELECT DISTINCT a, b FROM t) _，对比pg_stats.n_distinct是否偏差超过5倍；若偏差大，用ALTER TABLE t ALTER COLUMN a SET (n_distinct = X)硬编码修正——这是最后手段，但比坐等自动统计更新更可靠。
