outer apply用于右侧逻辑必须逐行依赖左表字段的场景，如子查询中引用u.id、调用表值函数或取top n记录；left join子查询无法访问外部列，会报“multi-part identifier could not be bound”错误。
OUTER APPLY 不是用来“替代 JOIN”的通用替换词，而是解决 LEFT JOIN 做不了的事——尤其是右侧逻辑必须逐行依赖左表字段时。 直接套用 OUTER APPLY 反而可能拖慢查询，甚至引发错误。
什么时候 LEFT JOIN 会报错，而 OUTER APPLY 可以跑通
典型错误是 The multi-part identifier "u.id" could not be bound。这发生在你试图在 LEFT JOIN 的子查询中引用左表字段：
SELECT u.name, sub.amount FROM users u LEFT JOIN ( SELECT TOP 1 amount FROM orders WHERE user_id = u.id -- ❌ 报错：u.id 不在子查询作用域内 ) sub ON 1=1
OUTER APPLY 允许右侧子查询直接访问 u.id，因为它是“按行执行”的：
SELECT u.name, sub.amount FROM users u OUTER APPLY ( SELECT TOP 1 amount FROM orders WHERE user_id = u.id -- ✅ 合法：u.id 在当前行上下文中可见 ORDER BY created_at DESC ) sub
- LEFT JOIN 子查询是“一次性物化”的，不能带外部变量
- OUTER APPLY 子查询是“每行调用一次”，天然支持相关引用
- 如果右侧只是静态表（如
SELECT * FROM orders），强行用 OUTER APPLY 属于画蛇添足，优化器难推导，性能反而可能下降
取每组最新/最贵一条记录（TOP N 场景）
这是 OUTER APPLY 最高频用途，LEFT JOIN + ROW_NUMBER() 虽能实现，但写法冗长、索引利用差、可读性低。
例如：每个用户最新一笔订单
SELECT u.name, o.order_id, o.created_at FROM users u OUTER APPLY ( SELECT TOP 1 order_id, created_at FROM orders o2 WHERE o2.user_id = u.id ORDER BY o2.created_at DESC ) o
- 必须加
TOP 1+ORDER BY，否则可能返回多行，导致结果集膨胀 - WHERE 条件中的
o2.user_id = u.id是强制要求，漏掉会报Invalid column name 'u' - 确保
orders(user_id, created_at)有复合索引，否则每次子查询都可能全表扫描
调用表值函数（TVF）必须用 OUTER APPLY
LEFT JOIN 根本不支持把 TVF 当作右表直接关联，语法直接拒绝：
SELECT u.name, t.tag_name FROM users u OUTER APPLY dbo.GetUserTags(u.id) t -- ✅ 唯一合法写法
- 如果是内联 TVF（inline TVF），SQL Server 可能将其内联展开，性能接近 JOIN
- 但如果是多语句 TVF（multi-statement TVF），每次调用都会产生额外开销，且行数估算不准，容易触发嵌套循环 × N 次执行
- 用
SET STATISTICS XML ON查看执行计划里 TVF 被调用了多少次，预估行数和实际行数是否严重偏离
容易被忽略的坑：WHERE 条件写在哪儿，结果天差地别
下面两个查询语义完全不同：
-- A. 过滤在 OUTER APPLY 内部 → 只查满足条件的最新订单 OUTER APPLY ( SELECT TOP 1 amount FROM orders WHERE user_id = u.id AND status = 'completed' ORDER BY created_at DESC ) o <p>-- B. 过滤在主查询 → 先取最新订单（不管 status），再筛 amount > 100 OUTER APPLY ( SELECT TOP 1 amount FROM orders WHERE user_id = u.id ORDER BY created_at DESC ) o WHERE o.amount > 100 -- ❌ 若无匹配，o.amount 是 NULL，整行被过滤掉（OUTER APPLY 行为被破坏）</p>
真正想保留所有用户、只对有匹配且满足条件的显示数据，得把条件收进子查询；若写在主 WHERE，就等价于 INNER JOIN 效果——那些没满足 o.amount > 100 的用户行会被干掉，OUTER APPLY 的“保留左表”特性就失效了。
