Hash Aggregate出现在执行计划中，说明优化器基于数据无序、量大且内存预估充足选择了哈希聚合；它全量构建哈希表后计算，不流式输出，若出现Hash bailout或Spill则需干预索引、统计或分组设计。
Hash Aggregate 出现在执行计划里，说明数据库优化器选择了哈希聚合算法来处理你的 GROUP BY 或无分组聚合（如 COUNT(*)），这不是错误，而是对当前数据特征和资源条件做出的主动选择。它通常意味着：输入数据未按分组列排序、数据量较大、内存足够或可控——此时哈希比排序更省时。
Hash Aggregate 为什么被选中？看三个关键前提
- 数据未排序：如果
GROUP BY列上没有可用的有序索引（比如缺失索引，或索引未覆盖所有分组字段），Sort Aggregate就得先排序再聚合，I/O 和 CPU 开销更高；而Hash Aggregate直接建哈希表，跳过排序。 - 表数据量大：当扫描行数超过几万甚至百万级，排序的代价呈 O(n log n) 增长，哈希则接近 O(n)，优势明显。
- 内存预估充足：优化器基于统计信息估算所需内存；若预估内存低于阈值（如 SQL Server 默认 25% 查询内存预算），它可能退回到
Sort Aggregate或触发溢出。
你可以在执行计划中右键点击 Hash Match (Aggregate) 节点 → 查看属性 → 检查 Estimated Number of Rows 和 Estimated Data Size，对比实际 Actual Number of Rows 是否严重偏差——统计信息陈旧是误选哈希的常见原因。
哈希聚合到底在内存里干了什么？
它不是边读边输出，而是全量构建哈希表后才开始计算并返回结果：
Unified LLM Gateway - One API for 70+ AI models. Route to GPT, Claude, Gemini, Qwen, Deepseek, Grok and more
下载
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- 对每一行，用
GROUP BY列值计算哈希，定位到哈希桶（bucket） - 若该桶为空，新建分组条目，初始化聚合状态（如
SUM=0、COUNT=0） - 若该桶已存在匹配分组，直接更新状态（如
SUM += value） - 所有行处理完后，遍历哈希表，对每个分组执行终值计算（如
AVG = SUM / COUNT）
这意味着：
-
Hash Aggregate无法流式输出，延迟高，不适合交互式分页场景 - 如果哈希表撑爆内存（例如分组数极多 + 行数极大），会把部分桶写入
tempdb或磁盘 workfile，出现Warning: Hash warning: Hash bailout，性能断崖下跌
怎么判断要不要干预？重点关注这几点
- 出现
Hash warning: Hash bailout或执行计划中带Spill Level > 0：说明内存不足，必须优化——要么加内存，要么减少分组基数（如改用日期截断代替完整时间戳分组），或加过滤条件缩小输入集 -
GROUP BY列上有高选择度索引但没走：检查是否在列上用了函数（如UPPER(name)）、隐式转换（varcharvsnvarchar）导致索引失效，让优化器“被迫”选哈希 - 查询带
ORDER BY且与GROUP BY完全一致：此时Sort Aggregate可能更优，可尝试加OPTION (USE PLAN N'...')强制或用 Hint（如 PostgreSQL 的/<em>+ NO_HASH_AGG </em>/）测试对比 - 并行度高但 CPU 持续打满：哈希聚合天然适合并行（各线程可独立建局部哈希表再合并），但若数据倾斜严重（某个分组占 80% 行数），会导致一个线程卡死——这时需要检查分组键分布，必要时加
APPROX_COUNT_DISTINCT或采样
哈希聚合本身不是性能问题的根源，而是数据库对现实约束（数据无序、内存有限、统计不准）的诚实回应。真正要盯住的，是它背后暴露的信号：索引缺失、统计过期、分组设计不合理，或者查询本就不该在 OLTP 实例里跑百万级聚合。
