cross apply 能真正替代 left join 的场景是右侧需逐行依赖左表字段且无法物化，如调用表值函数、取每行top n排序结果或拆分字符串；left join 无法表达此类动态逻辑。
什么时候CROSS APPLY能真正替代LEFT JOIN
不能。CROSS APPLY 本质上不是 LEFT JOIN 的“高效替代品”，而是解决一类 LEFT JOIN 根本无法表达的逻辑：右侧必须逐行依赖左表字段、且需控制返回行数（如 TOP + ORDER BY）或调用表值函数（TVF）。强行用 CROSS APPLY 去“替换”一个纯等值连接的 LEFT JOIN，不仅没收益，还可能干扰优化器——SQL Server 通常会把简单子查询形式的 CROSS APPLY 自动重写为等价 INNER JOIN，但语义模糊时反而失去优化空间。
CROSS APPLY 真正起效的典型场景
它生效的前提是右侧表达式“动态绑定左表当前行”，且该逻辑无法被提前物化。常见情况包括：
-
CROSS APPLY调用 TVF，参数来自左表字段，例如dbo.GetOrderDetails(o.OrderID) - 对每个左表行，取右表中按某条件排序后的前 N 条，例如
SELECT TOP 1 * FROM logs l WHERE l.UserID = u.ID ORDER BY l.Created DESC - 拆分字符串字段并关联（如用自定义 TVF 解析逗号分隔的标签），
CROSS APPLY dbo.ParseTags(u.Tags, ',')
这些场景下，LEFT JOIN 无法直接表达“每行独立 Top”或“逐行函数调用”，硬套 ROW_NUMBER() OVER (PARTITION BY ...) + 子查询虽可行，但可读性差、执行计划易退化。
LEFT JOIN 改写为 CROSS APPLY 的实操要点
若你确有需求将现有 LEFT JOIN 逻辑迁移到 CROSS APPLY（比如为了统一使用 TVF 或支持动态 TOP），注意三点：
- 原
LEFT JOIN若允许右表无匹配行，而你又需要保留左表行，那必须改用OUTER APPLY，不是CROSS APPLY—— 后者天然丢弃无结果的左行 - 子查询中所有对外部列的引用必须显式出现在
WHERE条件里，例如WHERE s.OrderID = o.OrderID，不能省略或写成别名歧义形式 - 若右侧子查询含
TOP但没ORDER BY，SQL Server 可能报错或返回非预期行；ORDER BY是强制要求，不可省略
性能差异往往藏在执行计划细节里
表面上 CROSS APPLY (SELECT ...) 和等价 INNER JOIN 执行计划相似，但关键区别在于：当右侧逻辑复杂（如嵌套 TVF、多层子查询），CROSS APPLY 强制采用嵌套循环（Nested Loops），而优化器对 JOIN 可能选择哈希或合并连接。这意味着数据量大时，前者容易因反复执行右侧逻辑拖慢整体速度。验证方式很简单：对比两者的实际执行计划，重点看右侧是否出现“Compute Scalar”+“Table Valued Function”节点，以及“Estimated Number of Executions”是否等于左表行数——如果是，就说明真正在逐行调用。
真正容易被忽略的是：CROSS APPLY 的“逐行”特性既是优势也是负担，它让逻辑清晰可控，也把性能瓶颈暴露得更彻底。写之前先问一句：这个右侧逻辑，是不是真的必须依赖当前左表行？如果不是，就别用 APPLY。
