嵌套查询误导优化器高估中间结果行数，导致granted_memory_kb远超实际需要；统计信息陈旧、table spool预估偏差大、参数化查询复用错误计划等加剧该问题，需结合option(recompile)、索引化临时表等手段精准控制内存申请。
嵌套查询本身不申请内存，但会误导优化器高估中间结果行数，导致 granted_memory_kb 远超实际需要——这是内存Grant过大的根本原因。
为什么执行计划里 granted_memory_kb 突然飙到 1GB？
SQL Server 不是按你写的 SQL 行数估算内存，而是按它“猜”的中间结果大小算。嵌套结构（尤其是多层 IN/EXISTS）会让优化器失去基数感知能力：
- 子查询返回 100 行，但外层 JOIN 后被放大成 200 万行，优化器却按 100 行估算 Sort 或 Hash Match 的内存
- 统计信息陈旧（比如小表 Customers 行数被记成 10 行，实际是 5 万），导致优化器误判为“小表”，强行选哈希连接并申请巨量内存
- 执行计划中出现
Table Spool (Eager Spool)节点，且其 Estimated Number of Rows 比实际大几个数量级
用 OPTION (RECOMPILE) 强制重估基数，但别乱加
当参数值极大影响结果集大小时（例如 WHERE status IN (@p1, @p2)，@p1 是 'active'，@p2 是 'deleted'），缓存的执行计划会复用错误基数。加 OPTION (RECOMPILE) 可让每次执行都基于真实参数重编译：
- 只对参数敏感的语句加，比如存储过程里传入城市名查订单；对固定值的报表 SQL 加了反而增加编译开销
- 必须配合
SET STATISTICS XML ON验证：重编译后执行计划里GrantedMemoryKB是否回落到合理范围（比如从 1024000 降到 8192） - 不能替代索引——如果子查询本身没走索引，重编译只是让优化器更准地“算错”，仍会申请大内存
把子查询提前物化成带索引的临时表
当嵌套逻辑复杂、无法用 JOIN 重写，或子查询结果要被多次引用时，显式控制中间结果比依赖优化器更可靠：
- 禁用
SELECT * INTO #tmp FROM (...)：生成的临时表无索引，后续所有操作都可能触发 TempDB spill - 改用三步法：
CREATE TABLE #tmp (id INT PRIMARY KEY); CREATE INDEX IX_tmp_status ON #tmp (status); INSERT INTO #tmp SELECT id FROM users WHERE status = 'active'; - 确保 JOIN 字段（如
user_id）在临时表上有索引，否则和原嵌套查询一样慢 - 注意生命周期：#tmp 在批处理结束自动释放，但若在循环中反复建删，改用表变量
@tmp（仅限小结果集，
真正关键的一步：别只盯着嵌套，先看驱动顺序对不对
内存 Grant 大，往往是因为优化器选了大表做外循环，引发海量内表扫描+重复哈希构建。重点不是“去掉嵌套”，而是让小结果集先出来：
- 把
IN (SELECT ...)改成INNER JOIN (SELECT ...)，明确告诉优化器“这个子查询是驱动源” - 给子查询的筛选列建覆盖索引，例如
CREATE INDEX IX_users_status_id ON users (status) INCLUDE (id)，让它能快速输出几千行 ID，而不是全表扫出百万行再过滤 - 如果改完还是大 Grant，用
sys.dm_exec_query_stats查last_grant_kb和last_used_grant_kb差值——差值大说明内存真浪费了，得调统计信息或加FORCE ORDER
最常被忽略的是：临时表没索引、小表统计信息没更新、以及把 OPTION (RECOMPILE) 当万能药——它解决的是“估算不准”，不是“结构低效”。先让数据路径变短，再让估算变准。
