CROSS APPLY 是解决逐行动态生成多行结果的唯一可行方案，嵌套子查询无法实现；其右侧必须是带别名的表表达式，且对左侧每行独立执行，易引发性能瓶颈。
CROSS APPLY 不是用来“替代嵌套查询”的语法糖，而是解决“逐行动态生成多行结果”这一类问题的唯一可行路径——嵌套子查询根本做不到。
为什么相关子查询在 SELECT 列表里会报错或失效
当你写 SELECT id, (SELECT name FROM Products WHERE id = Orders.product_id)，这能跑；但一旦右侧要返回多行（比如拆分字符串、解析 JSON、取 TOP N），SQL Server 就直接拒绝：Subquery returned more than 1 value。这不是限制严，是语义冲突：SELECT 列表要求标量值，而你塞了个结果集。
- 相关子查询只能用于标量上下文（WHERE、SELECT 单列、HAVING），不能返回行集
- 即使加了
TOP 1，它也只解决“不报错”，无法表达“每个订单对应 3 行商品明细”这种一对多映射 - 若强行用多层嵌套 + JOIN 模拟，SQL 会迅速变得不可读，执行计划也常退化为嵌套循环 + 重复扫描
CROSS APPLY 右侧必须是带别名的表表达式
常见错误是漏掉别名或误写括号结构，导致 Incorrect syntax near '('。CROSS APPLY 后面不是任意子查询，而是必须能被当作“临时表”看待的结构化表达式。
- 正确写法必须含显式别名：
CROSS APPLY (SELECT TOP 3 * FROM Orders o WHERE o.cust_id = c.id ORDER BY order_date DESC) AS last_orders - 调用表值函数时，函数本身已返回表，但仍需别名：
CROSS APPLY STRING_SPLIT(c.tags, ',') AS t - 不能省略
AS（哪怕只写AS t），也不能把函数调用包在多余括号里，如CROSS APPLY (dbo.SplitString(c.str, ','))是错的，应为CROSS APPLY dbo.SplitString(c.str, ',') AS s
STRING_SPLIT 和 OPENJSON 场景下必须处理顺序和 NULL
SQL Server 2016+ 的 STRING_SPLIT 默认不保证顺序，OPENJSON 对 NULL 字段默认跳过——这两点不手动干预，数据就错位。
- 用
STRING_SPLIT(c.tags, ',', 1)（第三个参数启用序号）后，必须ORDER BY t.ordinal才能对齐原始位置 - 字段存 JSON 数组（如
order_items NVARCHAR(MAX)值为[{"id":101,"qty":2}]），必须用CROSS APPLY OPENJSON(c.order_items) WITH (id INT '$.id', qty INT '$.qty')，否则无法展开成行 - 若原始字段为 NULL 或空字符串，
CROSS APPLY会跳过该行（OUTER APPLY才保留），注意是否符合业务预期
性能陷阱：右侧逻辑被反复执行，不是“一次计算复用”
CROSS APPLY 的本质是“对左侧每一行，独立执行一次右侧逻辑”。如果右侧是多语句 TVF、未索引的子查询或标量函数，耗时会随左侧行数线性放大。
- 检查执行计划中右侧操作符的
Actual Number of Executions—— 若等于左侧行数（比如 50 万次），且每次都有Clustered Index Scan，就是瓶颈 - 优先用内联 TVF（
RETURNS TABLE AS RETURN (SELECT ...)），避免多语句 TVF（BEGIN ... END）；后者无法内联，优化器完全无法优化 - 右侧若含
ORDER BY ... OFFSET 0 ROWS FETCH NEXT 3 ROWS ONLY，改用TOP 3+ 覆盖索引（排序字段 + 查询字段都包含） - 别在右侧写
WHERE col = dbo.Calc(x)这类标量函数调用；提前算好、加计算列、建索引，比在 APPLY 里每行重算强十倍
真正容易被忽略的是右侧表达式的“可见性边界”：CROSS APPLY 内部能引用左侧当前层级的列，但不能跨过一层子查询再引用——比如在右侧子查询里再套一层子查询，外层左表的列就不可见了。这种错误不会报语法错，但结果为空，调试起来极隐蔽。
