多层嵌套子查询本身不直接占用内存，但会导致优化器严重误估基数，使Sort或Hash Match算子在TempDB中大量spill；应通过执行计划查SpillLevel="1"定位，并删子查询ORDER BY、改IN为JOIN、物化加索引来切断膨胀链。
多层嵌套子查询本身不直接吃内存，但会让优化器彻底误判数据规模，导致Sort或Hash Match算子在TempDB里疯狂spill——这不是你SQL写得“错”，而是执行计划崩了。
为什么嵌套越深，TempDB越容易爆
SQL Server对嵌套结构的基数估算极不敏感。比如一个CTE或子查询返回10行，外层再JOIN一张百万级表，优化器仍可能按“10行 × 百万行 = 1000万”这种错误基数分配内存；实际执行时发现要处理2000万行，立刻溢出到TempDB。
- 每层嵌套都可能触发一次物化（Materialization）：MySQL叫
DERIVED，SQL Server叫Compute Scalar或Spool，都会往TempDB写中间结果 - 子查询里带
ORDER BY或DISTINCT？它不会被外层复用，纯属白占内存和排序区 - 视图定义含
GROUP BY+ 外层LIMIT？SQL Server会先排完全部千万行，再取前10条——ORDER BY发生在截断前
怎么一眼看出是嵌套惹的祸
别看SQL写了几层括号，直接查执行计划里的溢出信号：
- 开
SET STATISTICS XML ON，找<relop physicalop="Sort"></relop>或<relop physicalop="Hash Match"></relop>节点，看有没有SpillLevel="1"或警告文字"Operator used tempdb to spill data" - 运行
SELECT session_id, internal_objects_alloc_page_count FROM sys.dm_db_session_space_usage WHERE internal_objects_alloc_page_count > 100000，确认高消耗会话是否正在跑你的嵌套视图 - 用
EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）或EXPLAIN FORMAT=tree（MySQL），检查Plan Rows是否比你预期输出大几个数量级
绕过嵌套导致的spill，实操就三招
核心不是“去掉括号”，而是切断中间结果膨胀链：
- 删掉所有子查询里的
ORDER BY，除非配合LIMIT或TOP——它对外层无效，只增加spill风险 - 把
IN或EXISTS改写成JOIN (SELECT ...)，且确保子查询字段有覆盖索引，例如users(status, id) - 宽表视图+并发读？临时加
OPTION (LOOP JOIN, MAXDOP 1)压制Hash Match倾向，但前提是驱动表小、连接列有索引
真正难处理的，是那些没报错、没超时、但每次执行都悄悄往TempDB灌几十GB的查询——它们往往藏在视图或报表SQL里，靠常规监控根本抓不住，必须定期用sys.dm_db_session_space_usage扫一遍internal_objects_alloc_page_count。
