标量子查询引用外层字段会导致每行重复执行，性能极差；应改用OUTER APPLY配合覆盖索引（如IX_orders_user_date）实现Index Seek。
SELECT 列表里的子查询（标量子查询）只要涉及外层表字段，基本都会成为性能瓶颈——它强制 SQL Server 对外层每一行都重复执行一次内层查询，且难以重用执行计划。
为什么 (SELECT TOP 1 ...) 在 SELECT 里特别慢
这类写法在报表查询中很常见，但本质是“每行触发一次独立查找”。执行计划里常出现高频的 Compute Scalar 节点 + Clustered Index Scan 或全表扫描，尤其当外层返回几千行时，性能断崖式下跌。
- 优化器无法将它重写为索引查找，除非你明确告诉它“这是按某字段关联的一次性取值”
-
TOP 1单独存在无意义，必须配合ORDER BY，否则 SQL Server 可能忽略排序直接取物理首行 - 子查询若引用多个外层字段（如
u.id, u.region），索引设计难度陡增，容易退化为扫描
用 OUTER APPLY 替换是最直接有效的方案
它把语义从“计算一个值”显式转为“对每行做一次关联查找”，让优化器能稳定生成 Nested Loops + Index Seek。
- 右表子查询必须加别名（如
o），且字段要显式命名（AS last_order），否则外层无法引用 -
TOP 1 ORDER BY必须共存，且排序字段最好落在索引的右侧（如复合索引(user_id, order_date DESC)） - 如果业务允许结果为
NULL（比如用户从未下单），用OUTER APPLY；否则改用CROSS APPLY，但会丢掉无匹配的外层行
索引不配好，OUTER APPLY 也白搭
即使语法改对了，没有合适索引，照样扫全表。关键不是“有没有索引”，而是“索引是否覆盖查找+排序+输出字段”。
- 对于
WHERE o2.user_id = u.id ORDER BY order_date DESC，最优索引是：CREATE NONCLUSTERED INDEX IX_orders_user_date ON orders (user_id) INCLUDE (order_date) - 不要盲目建
(user_id, order_date)复合键——除非你还按order_date做范围查询或分组；否则INCLUDE更轻量、缓存更友好 - 如果子查询里还有
WHERE status = 'shipped'，这个status字段也得进INCLUDE，否则索引无法完成过滤
什么情况不该硬套 OUTER APPLY
不是所有 SELECT 里的子查询都适合改。盲目替换反而引入复杂度或语义偏差。
- 纯常量计算，如
(SELECT GETDATE())或(SELECT 100 * 0.05)：直接写死或用变量，OUTER APPLY完全没必要 - 右表结果固定、不依赖外层字段，如
(SELECT MAX(price) FROM products)：提前算成变量或用CROSS JOIN，比OUTER APPLY开销小得多 - 需要去重或聚合多行（如
COUNT(*)），这不是关联查找，而是每行触发一次聚合计算——应改用LEFT JOIN+ 派生表预聚合，或窗口函数
真正卡住性能的，往往不是语法本身，而是没意识到“标量子查询”和“关联查找”在执行引擎眼里是两类操作。改写只是第一步，索引是否贴合 OUTER APPLY 的访问模式，才是决定快慢的最后一环。
