为什么T-SQL中的CROSS APPLY有时候比普通的INNER JOIN快上好几倍？-SQL-PHP中文网

cross apply 并不天然比 inner join 快，其“更快”仅出现在右侧依赖左表字段的语义场景中，如逐行调用tvf、top n子查询或openjson解析；此时它使本不可写的高效逻辑成为可能，避免了全表窗口计算等低效替代方案，本质是能力边界而非性能优势。

为什么t-sql中的cross apply有时候比普通的inner join快上好几倍？

CROSS APPLY 并不天然比 INNER JOIN 快；所谓“快好几倍”只发生在特定语义下，且前提是右侧逻辑本身可优化——换言之，不是 APPLY 快，而是它让某些本不可写的高效逻辑变成了可能。

什么时候 CROSS APPLY 能“快”？关键看右侧是否依赖左表字段

INNER JOIN 的 ON 条件只能引用两张独立表的列，不能把左表字段当作右表子查询的输入参数。一旦你写成这样：

FROM Users u
INNER JOIN (SELECT * FROM Orders WHERE UserId = u.Id) o ON 1=1

SQL Server 直接报错：The multi-part identifier "u.Id" could not be bound. 这种写法根本通不过语法检查。

而 CROSS APPLY 允许右侧子查询或函数直接引用 u.Id，从而让“每行独立执行一次过滤”成为合法操作。这种逐行动态关联，是 INNER JOIN 做不到的语义——不是性能差异，是能力边界差异。

典型场景：取每个用户的最新订单（TOP 1 ... ORDER BY CreatedAt DESC）
典型场景：调用表值函数如 dbo.SplitTags(u.Tags)，输入随每行变化
典型场景：解析 JSON 字段 OPENJSON(u.ConfigJson)

为什么看起来“快”？其实是避免了低效替代方案

当必须实现“每行取 TOP N”时，若强行用 INNER JOIN，常见错误写法是：

FROM Users u
INNER JOIN (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY UserId ORDER BY CreatedAt DESC) rn
  FROM Orders
) o ON o.UserId = u.Id AND o.rn = 1

这个写法会先对全量 Orders 表做窗口计算，再 JOIN 过滤。如果 Orders 有千万行，ROW_NUMBER() 就得扫全表、排序、生成临时结果集——开销巨大。

而等价的 CROSS APPLY 写法：

FROM Users u
CROSS APPLY (
  SELECT TOP 1 * FROM Orders o WHERE o.UserId = u.Id ORDER BY CreatedAt DESC
)

只要 Orders(UserId, CreatedAt DESC) 有合适索引，每次执行都是索引 Seek + 单行返回，总耗时 ≈ 左表行数 × 单次 Seek 时间。

左侧 10 万用户 → 10 万次索引 Seek，毫秒级完成
右侧窗口方案 → 先全表扫描 + 排序 + 生成中间结果 → 可能秒级甚至分钟级
“快几倍”本质是算法复杂度从 O(N log N) 降到了 O(M × log K)，其中 M 是左表行数，K 是单个 UserId 对应的订单数

但 CROSS APPLY 本身不提速——拖慢它的往往是右侧子查询

如果你把 CROSS APPLY 当成“性能开关”乱用，反而会让查询变慢。真正影响性能的是右侧表达式的执行方式：

右侧用了多语句表值函数（MSTVF），比如含 BEGIN...END、临时表或循环 → 每次调用都触发额外编译和执行开销
右侧子查询没走索引，例如 WHERE o.UserId = u.Id ORDER BY o.Amount DESC 却没建 (UserId, Amount DESC) 索引 → 每行都全表扫描
右侧用了标量函数如 dbo.CalcScore(o.Amount) → 在左侧每行重复执行，无法内联优化
左侧大表（百万行）+ 右侧无索引子查询 → 实际执行计划变成嵌套循环 × 百万次低效扫描

查证方法很简单：SET STATISTICS XML ON，看执行计划里右侧操作的实际执行次数（Actual Number of Executions）是否等于左表行数，再对比 Estimated Rows 和 Actual Rows 是否严重偏离。

INNER JOIN 和 CROSS APPLY 的性能比较，只在“语义等价”时才有意义

当右侧是个静态表（比如 Cities），且不依赖左表字段时，下面两写法在 SQL Server 中通常生成完全相同的执行计划：

-- 写法1：INNER JOIN
FROM Users u
INNER JOIN Cities c ON c.RegionId = u.RegionId
<p>-- 写法2：CROSS APPLY
FROM Users u
CROSS APPLY (SELECT * FROM Cities WHERE RegionId = u.RegionId) c</p>

此时谈“谁更快”没有实际意义——优化器早就把它们归一化了。真正该关心的是：你写的逻辑，是否非得靠 CROSS APPLY 才能表达？如果是，那就用；如果不是，优先选 INNER JOIN，更直观、更通用、更少出错。

容易被忽略的一点是：CROSS APPLY 的右侧一旦返回空结果，整行就被丢弃；而很多人误以为这只是“写法不同”，却没意识到它隐含了严格过滤语义——这在调试时经常导致数据“莫名消失”。