嵌套子查询本身不减少临时表引用，反而因物化失控加剧膨胀；真正需解决“不该物化的被物化”和“该复用的没复用”——sql server对含group by、order by、top或聚合的子查询默认物化为derived表，重复引用时重算不缓存，cte需加materialized提示（2022+）才强制物化，超5000行中间结果必须显式建带索引的#temp表。
嵌套子查询本身不会减少临时表引用，反而容易因物化失控加剧临时表膨胀——真正要解决的是“不该物化的被物化”和“该复用的没复用”这两个问题。
为什么嵌套子查询会让SQL Server疯狂建临时表？
SQL Server对嵌套子查询的处理很直接：只要它不能下推、不能半连接优化，就默认物化成派生表（select_type = DERIVED），哪怕只用一次。尤其当子查询含GROUP BY、ORDER BY、TOP或聚合函数时，优化器几乎必然走物化路径。
- 外层
WHERE里多个地方重复引用同一子查询（比如IN+SELECT字段中又用一次），SQL Server不会自动缓存结果，每次调用都重算+重建临时结构 -
FROM (SELECT ...)这种派生表写法，在执行计划里显示为Compute Scalar或Table Spool节点，本质就是内存/TempDB临时表 - 子查询里用了
ORDER BY但没配TOP或OFFSET，SQL Server仍会申请排序空间，哪怕外层根本不需要顺序
用CTE替代嵌套，但必须加MATERIALIZED提示（SQL Server 2022+）
SQL Server 2022起支持MATERIALIZED CTE，这是明确告诉优化器“这段先算好、放TempDB、后续直接读”，比盲目嵌套靠谱得多。
WITH cn_users AS MATERIALIZED (
SELECT id FROM users WHERE region = 'CN'
), high_value_orders AS MATERIALIZED (
SELECT user_id FROM orders WHERE amount > 100 AND status = 'paid'
)
SELECT u.name
FROM users u
INNER JOIN high_value_orders h ON u.id = h.user_id
INNER JOIN cn_users c ON u.id = c.id;
- 没加
MATERIALIZED时，CTE只是逻辑重写，优化器仍可能展开成嵌套结构 - 加了之后，执行计划里能看到
Eager Spool节点，且Actual Number of Rows稳定，不会反复重算 - 注意：CTE物化只对当前查询生效，不跨语句；若需跨多步复用，还是得上
#temp表
临时表不是备选方案，而是必选项——当子查询返回 >5000 行时
一旦中间结果集超过几千行，CTE再怎么MATERIALIZED也扛不住反复扫描或JOIN开销。这时必须显式建#temp表，并立刻建索引。
- 别用
SELECT * INTO #tmp FROM (...)——它不带统计信息，后续JOIN全靠瞎猜行数 - 正确姿势：
CREATE TABLE #tmp (user_id INT PRIMARY KEY); INSERT INTO #tmp SELECT DISTINCT id FROM users WHERE ...; CREATE INDEX IX_tmp_user_id ON #tmp(user_id); - 索引建在JOIN或WHERE用到的字段上，否则
#tmp跟没建一样慢 - 如果中间结果要被多个后续查询用，别省那点
DROP TABLE动作，显式清理更可控
哪些嵌套子查询根本不用改？
不是所有嵌套都要拆。SQL Server对简单相关子查询（EXISTS、标量子查询）优化得很好，强行改成JOIN反而破坏执行计划。
-
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')—— 留着，优化器通常转成半连接 -
SELECT name, (SELECT TOP 1 created_at FROM orders WHERE user_id = u.id ORDER BY created_at DESC) last_order—— 这种标量关联，改JOIN要加ROW_NUMBER()，更重 - 子查询只返回单值且条件强（如
WHERE id = @id），深度2层以内，基本无压力
真正该动手的是那些被复制粘贴三次以上、含聚合/排序、或执行计划里已出现Spill to TempDB警告的嵌套块——它们不是语法问题，是数据流设计问题。
