OUTER APPLY专为子查询可能返回空结果设计，天然支持NULL填充，语义明确、性能更优；LEFT JOIN无法在右表子查询中引用左表字段，且不支持TOP/ORDER BY等操作，强行使用会导致全量扫描或执行计划退化。
OUTER APPLY 就是专为“子查询可能返回空结果”设计的，它天然支持 NULL 填充，比 LEFT JOIN + 子查询更可靠、更易读、性能通常更好。
为什么不能直接用 LEFT JOIN 替代 OUTER APPLY？
LEFT JOIN 要求右表是完整可枚举的集合，而子查询若依赖左表字段（比如 WHERE o.user_id = u.id），在 JOIN 语法里无法合法引用左表别名——SQL Server 会报错 Invalid column name 'u'。有人强行套 CTE 或派生表绕过，但会导致全量扫描右表，失去“逐行过滤”的优势。
- LEFT JOIN 的 ON 条件只能做等值/简单逻辑，不支持
TOP 1、ORDER BY、聚合等子查询特有操作 - 即使写成
LEFT JOIN (SELECT ...) AS o ON 1=1，优化器也极难生成嵌套循环+索引查找，大概率退化为哈希匹配或排序合并 - 语义模糊：LEFT JOIN 暗示“一对多关联”，而 OUTER APPLY 明确表达“对每行执行一次计算”
OUTER APPLY 中子查询返回空时，字段怎么变 NULL？
只要子查询没返回任何行，OUTER APPLY 就自动把右表所有列填为 NULL，无需额外判断。关键在于：右表子查询必须显式命名字段，且外层 SELECT 必须通过别名引用这些字段。
- 错误写法：
SELECT u.id, o.* FROM users u OUTER APPLY (SELECT TOP 1 order_date FROM orders WHERE user_id = u.id) o——o.*在 SQL Server 中不被允许（除非右表是 TVF） - 正确写法：
SELECT u.id, o.last_order FROM users u OUTER APPLY (SELECT TOP 1 order_date AS last_order FROM orders WHERE user_id = u.id ORDER BY order_date DESC) o - 如果
orders表中没有该user_id的记录，o.last_order就是NULL，不是缺失字段
什么时候该用 OUTER APPLY，而不是 CROSS APPLY？
选 OUTER APPLY 的唯一判断标准是：业务是否要求“左表每一行都必须出现在结果中”，哪怕右表无匹配数据。例如查用户信息+最新订单时间，没下过单的用户也要显示——这时必须用 OUTER APPLY。
- CROSS APPLY 等价于 INNER JOIN：只保留右表有结果的左表行；OUTER APPLY 等价于 LEFT JOIN：左表全保留
- 若右表逻辑含
WHERE ... IS NOT NULL或强制非空约束（如主键关联），两者结果可能一致，但语义和执行计划仍不同 - 不要为了“省一行代码”而用 CROSS APPLY +
ISNULL()模拟 NULL 行为——这会让优化器误判数据分布，索引失效风险陡增
容易被忽略的性能陷阱
OUTER APPLY 不等于自动高性能。它的效率高度依赖右表是否有覆盖索引，且子查询结构是否稳定可优化。
- 必须确保右表 WHERE 条件字段（如
user_id）和 ORDER BY 字段（如order_date）组成复合索引，例如CREATE INDEX IX_orders_user_date ON orders(user_id, order_date DESC) - 避免在子查询里用
SELECT *或未限定 schema 的对象名（如dbo.orders比orders更易复用执行计划） - 如果右表数据量极大（比如日志表），且左表行数多，OUTER APPLY 可能触发大量索引查找——此时应评估是否改用预先聚合（如物化视图）或应用层分页
真正难的是让优化器相信“这个子查询每次只查几行”，而不是把它当成一个黑盒反复重编译。索引、参数化、字段显式命名，三者缺一不可。
