必须用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场景支持批处理模式加速，但前提是右端函数或子查询能向量化——目前支持有限，别默认指望
最麻烦的不是语法写不对，而是右端计算在每行上重复执行却没意识到开销；上线前务必在真实数据量下看执行计划和实际耗时。
