直接用 OUTER APPLY 替代标量子查询可解决90%性能问题，因其避免每行触发内层全表扫描，改用 Nested Loops + Index Seek，并需右表建覆盖索引、显式别名与字段命名。
直接用 OUTER APPLY 替代标量子查询，90% 的性能问题当场消失；硬扛嵌套、加索引或调 MAXDOP 都是治标不治本。
标量子查询为什么在SQL Server里特别慢
它不是语法错，而是执行模型天生不利：只要子查询引用了外层字段（比如 WHERE o.user_id = u.id），SQL Server 就把它标记为“相关子查询”，执行计划里必然出现 Compute Scalar 节点，且 EstimateRebinds > 1——这意味着每行外层数据都触发一次完整内层扫描。
- 常见错误现象：
SELECT * FROM users u WHERE (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) > 5，users 表 10 万行，实际执行了 10 万次 orders 表扫描 - 哪怕 orders 上有
user_id索引，也救不了——因为优化器无法把外层u.id提前绑定进索引查找路径 -
GETDATE()、NEWID()、未参数化的变量（如拼接的'2023-' + @month）会让子查询进一步被标为Uncacheable，彻底放弃复用
OUTER APPLY 是最稳的改写方式
它把“每行执行一次”的语义显式暴露给优化器，SQL Server 更愿意生成 Nested Loops + Index Seek 组合，前提是右表有合适索引。
- 必须加别名（如
o），且子查询中字段要显式命名（AS last_order），否则外层无法引用 -
TOP 1必须配ORDER BY，否则 SQL Server 可能忽略排序，取到非预期行 - 确保右表有覆盖索引，例如
orders(user_id, order_date)，否则仍会回表或全扫 - 语义注意：
OUTER APPLY允许右表无结果（返回NULL），CROSS APPLY则只保留匹配行——选哪个取决于业务是否接受空值
三层以上嵌套时，别信 CTE 能自动优化
SQL Server 的 CTE 不是物化容器，只是逻辑命名；如果最内层子查询本身含聚合、ORDER BY 或跨表关联，CTE 只是把嵌套“换个写法”，执行计划照旧崩。
- 真正有效的拆解是：用
SELECT INTO #tmp显式物化最稳定的一层（如基础订单筛选），再建索引（CREATE CLUSTERED INDEX IX_tmp_user ON #tmp(user_id)） - CTE 只在中间结果被多次引用（≥2 次）或需传参（如
@start_date）时才值得引入；否则纯属增加解析开销 - 视图嵌套超过 3 层，优化器大概率放弃代价估算，执行计划随机漂移——这不是你写得不好，是它“算不过来”
容易被忽略的细节：物化时机和 NULL 处理
很多人改完 OUTER APPLY 还慢，卡在两个隐形环节：一是没意识到右表结果为空时，OUTER APPLY 返回的是 NULL，但外层 WHERE 若写成 o.last_order > '2023-01-01'，会自动过滤掉这些行（等效于 CROSS APPLY）；二是物化临时表后忘了建索引，JOIN 时又退化成哈希匹配或嵌套循环全扫。
