嵌套查询不直接写入tempdb，真正触发溢出的是排序、哈希、去重等操作；改写关键在于切断中间结果膨胀链，而非单纯去掉嵌套。
嵌套查询本身不直接写入 TempDB，真正触发 TempDB 溢出的是其附带的排序、哈希、去重或游标快照等操作；改写重点不在“去掉嵌套”，而在切断中间结果膨胀链。
为什么 ORDER BY / GROUP BY 会把数据刷进 TempDB
SQL Server 对 ORDER BY、GROUP BY、DISTINCT 的执行依赖内存中的 worktable；当估算行数 × 每行大小超过内存授予（grant）时，就会 spill 到 TempDB。嵌套查询常让优化器误估基数（比如子查询返回 10 行，但外层 JOIN 后膨胀成 50 万行），导致 grant 不足。
- 用
SET STATISTICS XML ON执行语句，看执行计划中 Sort / Hash Match 节点是否有SpillLevel="1"或警告 “Warning: Operator used tempdb to spill data” - 避免在子查询里做
ORDER BY（除非配合TOP）——它不会被外层继承，纯属白占内存 - 如果外层必须排序，把
ORDER BY移到最外层，且确保排序字段上有索引：比如SELECT * FROM (SELECT id, name FROM users WHERE status = 'active') t ORDER BY id，比在子查询里ORDER BY name更安全
嵌套 + DISTINCT 导致 TempDB 爆涨的真实原因
不是 DISTINCT 本身慢，而是嵌套结构让 SQL Server 无法复用已排序的输入流，被迫新建 hash table 去重。常见于 SELECT DISTINCT col FROM t1 WHERE col IN (SELECT col FROM t2) 这类写法。
- 先确认子查询是否真需
DISTINCT：如果t2.col本身是主键或有唯一约束，外层DISTINCT就是冗余的 - 改用
INNER JOIN+ 显式GROUP BY替代：例如SELECT t1.col FROM t1 INNER JOIN (SELECT DISTINCT col FROM t2) t2 ON t1.col = t2.col GROUP BY t1.col，可让优化器走 merge join（若两边都有索引） - 若必须保留嵌套，加
OPTION (RECOMPILE)让优化器基于实际参数重估基数，有时能避免 spill
临时表中间结果没索引，是 TempDB 溢出的最大隐性推手
很多人用 SELECT INTO #tmp 快速落地中间结果，却忘了它生成的临时表默认无任何索引，后续所有 JOIN、WHERE、ORDER BY 都只能全表扫描 + 再次 spill。
- 禁用
SELECT INTO #tmp，改用显式建表：CREATE TABLE #tmp (id INT, status VARCHAR(20), created_time DATETIME); CREATE CLUSTERED INDEX IX_tmp_id ON #tmp (id); - INSERT 前就建好非聚集索引（尤其用于 JOIN 或过滤的字段）：
CREATE NONCLUSTERED INDEX IX_tmp_status_time ON #tmp (status) INCLUDE (created_time); - 如果中间结果只读且小（@tmp，它不走 TempDB 日志，也不会触发统计信息更新开销
真正卡住人的从来不是“要不要改嵌套”，而是改完后有没有盯住执行计划里的 SpillToTempDb 和 EstimatedRows —— 如果这两个没变，说明你只是换了语法，没动根子。
