子查询本身不写入tempdb，真正触发tempdb空间占用的是其附带的排序、哈希、去重等物理操作；嵌套+order by是最隐蔽的泄漏点，应删掉子查询内无意义的order by，仅保留在最外层且确保排序字段有索引。
子查询本身不写TempDB，但排序/哈希/去重会强制物化
子查询语句（如 SELECT * FROM (SELECT id, name FROM users WHERE status = 'active') t）不会自动写入 TempDB。真正触发空间占用的是其附带的物理操作：比如外层加了 ORDER BY、GROUP BY、DISTINCT，或子查询内用了 ROW_NUMBER() 等窗口函数。SQL Server 一旦判断无法流式处理，就会把中间结果“物化”到 TempDB —— 这不是语法错误，而是执行计划的选择。
嵌套 + ORDER BY 是最隐蔽的 TempDB 泄漏点
常见误写：SELECT * FROM (SELECT id, name FROM orders ORDER BY created_time) t WHERE id > 1000。这个 ORDER BY 在子查询里毫无意义：外层不继承排序，SQL Server 只能先全量排序再过滤，全程走 TempDB。更糟的是，如果 created_time 没索引，Sort 算子必然 spill。
- 删掉子查询里的
ORDER BY，只保留在最终查询顶层（且确保字段有索引） - 用
SET STATISTICS XML ON查执行计划，确认<relop physicalop="Sort"></relop>节点是否带SpillLevel="1" - 若必须提前排序（比如配合
TOP），改写为SELECT TOP N ... ORDER BY，让优化器识别可终止流式处理
CTE 和视图中的聚合/窗口函数极易隐式物化
像 WITH cte AS (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts) rn FROM logs) 这类 CTE，只要外层引用了 rn 或加了 WHERE rn = 1，SQL Server 几乎必然把整个 logs 表物化进 TempDB —— 尤其当 logs 是千万级且无 user_id, ts 覆盖索引时。
- 检查执行计划中是否有
Window Spool或Compute Scalar节点，它们常伴随高EstimateRows和大量TempDbPages - 避免在 CTE 内做跨大表的
PARTITION BY；优先考虑用聚合后JOIN替代窗口函数 - 对高频使用的视图，禁用其中的
ORDER BY和TOP，由调用方控制分页和排序
临时表没索引是溢出的最大隐性推手
很多人用 SELECT INTO #tmp FROM (...子查询...) q 快速落地中间结果，却忘了 #tmp 默认零索引。后续所有 JOIN、WHERE、GROUP BY 都只能全表扫描，再触发一轮 Hash Match 或 Sort，二次写满 TempDB。
- 禁用
SELECT INTO #tmp，改用显式建表 + 索引：先CREATE TABLE #tmp (...)，再CREATE CLUSTERED INDEX和关键字段的NONCLUSTERED INDEX - 索引字段要覆盖后续 JOIN 条件、WHERE 过滤列、GROUP BY 字段 —— 不是越多越好，而是让下个操作能走 Seek 而非 Scan
- 用
sys.dm_db_session_space_usage监控internal_objects_alloc_page_count，飙升就说明又在重复物化
真正难缠的从来不是“写了子查询”，而是子查询让优化器失去了流式处理能力，又没给它足够内存和索引支撑。物化不是 bug，是 fallback；而你得知道 fallback 发生在哪、为什么发生、以及怎么绕过它。
