相关子查询慢是因SQL Server 2019优化器无法缓存结果，导致外层每行重复执行，可通过XML执行计划中EstimateRebinds>1或Table Spool确认；改写为JOIN/EXISTS未必有效，根本解法是用带索引的临时表物化稳定子查询。
相关子查询慢，不是写法“不对”，而是 SQL Server 2019 的优化器在特定条件下根本没法缓存或重用结果——它被外层每一行反复执行，Rebinds 值飙高就是铁证。
怎么看是不是相关子查询在反复执行
别只看执行计划图形界面里有没有“子查询”字样。真正关键的是打开 SET STATISTICS PROFILE ON 后的实际执行计划 XML：
- 搜
RelOp节点下带EstimateRebinds属性的子节点，值 > 1 就是实锤（比如 5000 表示被调用了 5000 次） - 看到
Compute Scalar下挂了个Table Spool (Lazy Spool)，基本等于宣告“不可缓存” - 子查询里引用了外层表字段（如
WHERE status = u.status），就必然触发依赖型重算 - 哪怕你写成
CROSS APPLY，只要子查询里有t1.col这种引用，照样进 Nested Loops 内侧循环，逃不掉 Rebinds
为什么 JOIN / EXISTS 不总能解决问题
很多人直接把 IN 改成 JOIN 或 EXISTS，但效果没变——因为问题不在语法，而在数据分布和估算偏差：
-
EXISTS确实通常比IN快，但若子查询返回大量匹配行，且外层表很大，仍可能退化为嵌套循环 -
JOIN在统计信息不准、行数估算严重偏离（比如预估 1 行，实际 10 万行）时，优化器会错误选择 Hash Join 或 Merge Join，反而更慢 - 含
GETDATE()、NEWID()或未参数化的变量（如拼接字符串）的子查询，会被标记为UNCACHEABLE，强制每次重算，改写语法也无效
用临时表物化最内层子查询
这是绕过优化器误判最稳的一招，尤其适用于三层以上嵌套、含 GROUP BY 或 ORDER BY 的子查询：
- 先抽离最深、最稳定、不依赖外层列的子查询，用
SELECT INTO #tmp FROM (...) AS x物化到临时表 - 立刻给
#tmp加索引：CREATE CLUSTERED INDEX IX_tmp_id ON #tmp(id)—— 没索引的临时表 JOIN 时照样扫全表 - 外层查询改用
JOIN #tmp替代原子查询，执行计划彻底扁平，逻辑读、CPU 时间通常直降 50%+ - 注意：不要用
DECLARE @table表变量，它没统计信息，优化器无法估算行数，容易选错连接方式
容易被忽略的细节
物化临时表看似简单，但漏掉任意一步，性能提升就打折扣：
-
SET STATISTICS XML OFF和SET STATISTICS IO OFF要提前关掉，否则干扰执行计划输出 - 临时表名不能重复，否则下次执行会报错；建议加时间戳或
NEWID()后缀（如#tmp_20260721） - 如果子查询本身含聚合或窗口函数，物化后记得检查是否需要
OPTION (RECOMPILE)让优化器重新估算 - 物化操作本身有开销，只对 Rebinds > 100 或逻辑读 > 10000 的子查询才值得做——先用
SET STATISTICS IO ON确认成本再动手
