group by 触发 hash match (aggregate) 是因为输入数据未按分组列排序，导致流聚合不可用；常见原因包括函数破坏索引、隐式转换、order by 干扰及统计信息过期。
GROUP BY 为什么触发 Hash Match (Aggregate) 而不是 Stream Aggregate
因为输入数据没按 GROUP BY 列排序，流聚合（Stream Aggregate）就不可用——它必须依赖有序输入才能边读边分组。一旦优化器发现数据无序，又没法靠索引直接提供有序扫描，就只能退到哈希聚合。
常见破坏排序的写法包括：
-
GROUP BY UPPER(name)或GROUP BY DATE(created_at)：函数导致索引失效，排序路径断掉 -
WHERE user_id = 123但user_id是varchar类型：隐式转换让索引无法用于排序 -
ORDER BY created_at和GROUP BY user_id混用：ORDER BY 非分组列会干扰流聚合所需的物理顺序 - 统计信息过期，优化器误判行数，高估哈希溢出风险，宁可多一次
Sort也不信流聚合能稳住
怎么一眼确认是不是真走了 Hash Match (Aggregate)
别只看“用了索引”，重点盯执行计划里的三个信号：
- 节点类型是
Hash Match (Aggregate)，且鼠标悬停显示Warning: Operator used tempdb - 节点属性里
SpillLevel > 0（SQL Server）或Hash warning: Hash bailout（PostgreSQL） - 配合
SET STATISTICS IO ON查逻辑读：如果表只有 500 万行，但逻辑读达 2000 万+，大概率在反复读写临时页
Hash Match (Aggregate) 不等于慢，但溢出到 TempDB 就危险了
哈希聚合本身是内存操作，快；但一旦内存不够，就会 spill 到磁盘——这时你看到的不是延迟上升，而是 Could not allocate space for object 'dbo.#hash_table' in database 'tempdb' 这类报错。
溢出主因有四个：
- GROUP BY 字段无索引，或数据分布极不均匀（如大量
NULL、极高重复率） - 估算行数严重偏低（统计信息过期、CTE/视图隐藏基数），哈希表预分配内存不足
- 启用了
READ_COMMITTED_SNAPSHOT，同时有长事务更新基表，版本链全堆在 TempDB - 并行执行下每个线程独立申请 TempDB 空间，总量翻倍
真正难调的不是“怎么让它用 Hash Match”，而是“为什么该用 Stream Aggregate 却没用”
这往往意味着你漏掉了某个关键约束点：
- 索引是否覆盖全部
GROUP BY列，且没有函数封装？比如建了IX_orders_user_id_created_date，但写的是GROUP BY DATE(created_date)，索引就白搭 - 执行计划里有没有被隐藏的隐式转换？右键
Index Scan→ 属性 → 看Warnings栏是否出现Convert提示 - 统计信息是否最新？查
sys.dm_db_stats_properties，确认modification_counter是否远超阈值
这些点通常在开发环境测不出，一上生产，数据量和并发一起上来，TempDB 就开始报警。
