标量子查询在where或select中易致性能问题，应优先用outer apply替代；其明确表达每行关联执行逻辑，配合合适索引可稳定生成嵌套循环+索引查找，但需注意右表索引覆盖、数据量匹配及null语义。
标量子查询在WHERE或SELECT里拖慢查询，优先考虑OUTER APPLY
SQL Server中，WHERE或SELECT子句里写(SELECT TOP 1 ...)这类标量子查询，尤其是引用了外层表字段的“相关子查询”，很容易变成性能黑洞——执行计划里常看到Compute Scalar节点反复调用，每行都触发一次内层扫描。
根本问题不是语法错，而是优化器难以重用执行路径。而OUTER APPLY明确表达了“对左表每行，执行一次右表逻辑”，SQL Server能更稳定地生成嵌套循环（Nested Loops）+ 索引查找（Index Seek）组合，尤其当右表有合适索引时。
- 适用场景：SELECT列表中需要关联聚合、TOP 1 关联记录、或带条件计算字段（如最近订单时间、最新状态）
- 不适用场景：纯常量计算（如
(SELECT GETDATE())）、或右表结果固定且无外层依赖（这种直接用变量或CTE更轻） - 关键区别：
OUTER APPLY允许右表返回0行（对应NULL），CROSS APPLY则只保留右表有结果的左表行——选哪个取决于业务是否接受NULL
把SELECT里的标量子查询替换成OUTER APPLY的实际写法
原始写法常见于报表类查询：
SELECT u.id, u.name, (SELECT TOP 1 order_date FROM orders o WHERE o.user_id = u.id ORDER BY order_date DESC) AS last_order FROM users u
改成OUTER APPLY后：
SELECT u.id, u.name, o.last_order FROM users u OUTER APPLY ( SELECT TOP 1 order_date AS last_order FROM orders o2 WHERE o2.user_id = u.id ORDER BY order_date DESC ) o
注意三点：
- 子查询必须加别名（这里是
o），且字段要显式命名（AS last_order），否则外层无法引用 -
TOP 1+ORDER BY必须共存，否则TOP无意义，SQL Server可能忽略排序直接取物理第一行 - 确保
orders(user_id, order_date)上有复合索引，否则OUTER APPLY仍会走全表扫描
WHERE里用标量子查询过滤？OUTER APPLY + WHERE IS NOT NULL更可控
比如想查“有订单且订单金额大于用户平均订单额的用户”，原写法：
SELECT * FROM users u WHERE (SELECT AVG(amount) FROM orders o WHERE o.user_id = u.id) > 1000
这种写法在users表大、很多用户没订单时，AVG()会为每行都跑一次空聚合，效率极低。改用OUTER APPLY配合WHERE判断：
SELECT u.* FROM users u OUTER APPLY ( SELECT AVG(amount) AS avg_amount FROM orders o WHERE o.user_id = u.id ) a WHERE a.avg_amount > 1000
优势明显：
- 空订单用户，
a.avg_amount为NULL，WHERE a.avg_amount > 1000自然跳过，避免无效聚合 - 执行计划里能看到清晰的
Apply节点，方便确认是否用了索引查找 - 如果后续还要用
avg_amount做其他计算（比如和总销售额比），字段已就位，不用重复写子查询
容易被忽略的坑：OUTER APPLY不是万能加速器
换掉标量子查询不等于自动变快，以下情况反而更慢：
- 右表没有覆盖索引，尤其
WHERE条件字段和ORDER BY字段不在同一索引里——这时OUTER APPLY只是把扫描从子查询挪到了Apply节点，本质没变 - 左表数据量极大（千万级），但右表结果集也很大（比如每个用户平均有上千订单），
OUTER APPLY会放大IO压力，此时应先聚合右表（如用CTE预计算每位用户的last_order）再JOIN - 误用
CROSS APPLY替代OUTER APPLY导致数据丢失，特别是业务逻辑本应包含“无订单用户”的场景
真正省事的优化，永远从执行计划开始：先看原标量子查询是不是真走Index Seek，再看改完OUTER APPLY后，Estimated Number of Executions是不是和左表行数一致，以及Actual Number of Rows Read有没有明显下降。
