SQL Server CROSS APPLY / OUTER APPLY 的典型使用场景

必须用CROSS appLY而非JOIN时：右表表达式依赖左表字段且为表值函数、相关子查询或VALUES构造，如调用dbo.GetCitiesByRegionId(u.RegionId)；普通JOIN无法在FROM中引用左表列。

什么时候必须用 CROSS APPLY 而不是 JOIN

当你右边的表表达式依赖左边行的值，且该表达式是函数（如表值函数）、子查询或 VALUES 构造，而 sql Server 不允许在 FROM 子句中直接对普通 JOIN 的右端引用左表列时，CROSS APPLY 就成了唯一选择。

典型例子：对每行调用自定义表值函数（TVF）并展开结果：

select u.Name, c.CityName   FROM Users u   CROSS APPLY dbo.GetCitiesByRegionId(u.RegionId) c;

这里 dbo.GetCitiesByRegionId(u.RegionId) 是内联表值函数，它的参数 u.RegionId 来自左表 Users —— 普通 INNER JOIN 无法做到这点。

• JOIN 要求右表是“静态”关系；APPLY 允许右端是“相关计算”
• 如果 TVF 是多语句 TVF（MSTVF），性能可能显著下降，因为 SQL Server 往往给它估行数为 1，导致计划失真
• 用 CROSS APPLY 替代 JOIN + WHERE 子查询时，逻辑更清晰，但需注意空结果会被过滤掉（类似 INNER JOIN）

OUTER APPLY 等价于左连接，但能干 LEFT JOIN 干不了的事

OUTER APPLY 和 LEFT JOIN 都保留左表所有行，区别在于右端是否允许“按行计算”。只要右端依赖左表字段、又想保留无匹配的左行，就必须用 OUTER APPLY。

常见场景：查每个用户的最新一条订单，没订单也要显示用户信息：

SELECT u.Name, o.OrderDate, o.Amount   FROM Users u   OUTER APPLY (       SELECT TOP 1 OrderDate, Amount       FROM Orders o2       WHERE o2.UserId = u.Id       ORDER BY OrderDate DESC   ) o;

这个子查询含 WHERE o2.UserId = u.Id，且带 TOP 1 + ORDER BY，无法直接塞进 LEFT JOIN 的 ON 条件里（会报错或语义错误）。

• 若改用 LEFT JOIN + 窗口函数（如 ROW_number()），得先写 CTE 或子查询，代码变长，可读性下降
• OUTER APPLY 的右端返回空结果集时，对应列自动为 NULL，行为稳定
• 注意：OUTER APPLY 不等于 LEFT JOIN (SELECT ...) ON 1=1 —— 后者右端不相关，无法引用左表列

用 APPLY 解析 jsON 或字符串拆分（SQL Server 2016+）

SQL Server 2016 引入 OPENjson 和 STRING_SPLIT，它们都返回表，且天然适合配合 APPLY 使用，因为输入值来自左表每行。

例如：解析用户配置 JSON 字段中的权限列表：

SELECT u.Name, p.value AS Permission   FROM Users u   CROSS APPLY OPENJSON(u.ConfigJson, '$.Permissions') p;

又如：把逗号分隔的标签字符串展开成多行：

SELECT b.Title, t.value AS Tag   FROM BlogPosts b   CROSS APPLY STRING_SPLIT(b.Tags, ',') t;

• STRING_SPLIT 不保证顺序（SQL Server 2022+ 可加 ordinal 参数），若需序号，得用 OPENJSON 或自定义拆分函数
• OPENJSON 默认只返回 value，要取 key 或 type 需显式指定 WITH 子句
• 这些函数本身不走索引，大数据量时慎用；若频繁解析，建议提前物化到关联表中

容易踩的坑：性能与 NULL 处理

APPLY 看似简洁，但执行计划里常表现为嵌套循环（Nested Loops），尤其当右端是 MSTVF 或复杂子查询时，性能可能陡降。

• 检查执行计划：右端操作是否被反复执行（“Estimated Number of Executions” 很高）
• 避免在 APPLY 右端写未参数化的子查询（如漏掉 WHERE 关联条件），会导致笛卡尔积
• CROSS APPLY 会丢弃右端无结果的左行；误用它替代 OUTER APPLY 是常见逻辑错误，尤其在“查最新记录”类需求中
• SQL Server 2019+ 对某些 APPLY 场景支持批处理模式加速，但前提是右端函数或子查询能向量化——目前支持有限，别默认指望

最麻烦的不是语法写不对，而是右端计算在每行上重复执行却没意识到开销；上线前务必在真实数据量下看执行计划和实际耗时。