最常见错误是8645：“由于内存授予（排序和哈希）没有内存，无法执行查询”，主因是预估偏差大、并发紧张或统计信息陈旧导致hash aggregate内存需求超限。
SQL Server 2019 中因 GROUP BY 过于复杂（如多列 + 大数据量 + 非覆盖索引）触发内存授予失败，最常见错误是 8645：“由于内存授予（排序和哈希）没有内存，无法执行查询”。这不是服务器整体内存不足，而是单个查询申请的内存超出了 SQL Server 当前能安全分配的上限——它会直接中止，不降级、不换算法。
为什么 GROUP BY 容易触发 8645 错误
SQL Server 对每个查询的内存授予（memory grant）是预估的，基于统计信息和执行计划。复杂分组通常走 Hash Aggregate 或 Sort + Stream Aggregate，这两者都需要连续大块内存。一旦预估偏差大（比如统计信息陈旧、数据倾斜严重），或并发查询太多导致总授予池紧张，8645 就会出现。
-
GROUP BY列越多、数据类型越宽（如nvarchar(4000)）、结果集基数越低（分组后只剩几百行但中间要处理千万行），Hash Aggregate 内存需求指数级上升 - 如果
GROUP BY字段没索引，SQL Server 必须先排序或建哈希表，无法流式聚合（Stream Aggregate），强制走高内存路径 -
max server memory (MB)设得过高（比如 >90% 物理内存），反而会让 SQL Server 更激进地预估单个查询内存，放大预估误差风险
快速验证是否是内存授予问题
不要只看任务管理器或 sys.dm_os_process_memory ——它们反映的是整体内存占用，不是查询级授予瓶颈。重点查两处：
- 执行失败的查询时，捕获实际报错：必须是
8645或带 “memory grant” 关键词的警告（例如在 SSMS 的“消息”窗口里看到 “Warning: The query memory grant was adjusted...”） - 运行以下语句查最近的授予失败记录：
SELECT * FROM sys.dm_exec_query_memory_grants WHERE grant_time IS NULL AND wait_time_ms > 0;
返回非空，说明有查询卡在等内存授予 - 确认当前实例的授予上限：
SELECT value_in_use FROM sys.configurations WHERE name = 'max server memory (MB)';
再查实际可用授予池：SELECT SUM(granted_memory_kb)/1024. AS granted_mb FROM sys.dm_exec_query_memory_grants;
若后者长期接近前者 75%，说明池已紧绷
绕过或降低内存授予需求的实操手段
核心思路：不让 SQL Server 走 Hash/Sort Aggregate 路径，或缩小其输入规模。
- 给
GROUP BY字段加覆盖索引（含INCLUDE所需聚合列），强制引擎走Stream Aggregate——它几乎不占额外内存。例如：CREATE INDEX IX_Tbl_A_B_C_IncVal ON dbo.TableA (ColA, ColB, ColC) INCLUDE (ValueCol);
- 用
TOP+OFFSET分页分批聚合，避免一次性加载全量数据。例如把GROUP BY A, B拆成按A分片：SELECT A, B, SUM(Value) FROM TableA WHERE A IN (SELECT TOP 1000 A FROM TableA ORDER BY A) GROUP BY A, B;
再循环取下一批 - 显式控制内存：在查询开头加
OPTION (MAX_GRANT_PERCENT = 5)（SQL Server 2019+ 支持），限制该查询最多拿总授予池的 5%。虽可能变慢，但能避免直接失败 - 禁用并行（仅临时应急）：
OPTION (MAXDOP 1)。并行哈希会乘以线程数申请内存，单线程反而更稳——代价是 CPU 时间变长
容易被忽略的底层配置点
很多 DBA 以为调了 max server memory 就万事大吉，其实还有两个隐性开关在背后起作用：
-
min server memory (MB)如果设得过高（比如 16GB），会导致 SQL Server 即使空闲也不释放内存，留给查询授予池的“弹性空间”变小——建议保持默认0 - PolyBase 默认开启且 TCP 禁用时，会在
\Log\Polybase\dump\下狂写日志，吃光 C 盘；而 C 盘满会导致 Windows 分页文件异常，间接引发 SQL Server 内存分配失败（报错可能是701或17890，而非8645）。务必检查C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log\Polybase\dump是否存在数百 MB 的 .log 文件 - Windows 的 “锁定内存页” 权限（Lock Pages in Memory）若未启用，SQL Server 在内存压力下会被 OS 强制分页，此时哪怕
max server memory没到上限，也会因物理页被换出而无法满足授予请求
