必须用CROSS APPLY而非JOIN，因其右端可依赖左表字段执行动态计算，如表值函数、相关子查询或参数化VALUES；JOIN右端须为静态关系，无法引用左表列。
必须用 CROSS APPLY 而不是 JOIN，是因为右侧表达式依赖左表字段且是表值函数、相关子查询或 VALUES 构造——JOIN 的右端不允许引用左表列，而 APPLY 天然支持“每行计算”。这不是语法糖，是能力边界问题。
什么时候非用 CROSS APPLY 不可
当右侧是表值函数（TVF）、含 WHERE 引用左表列的子查询，或 VALUES 列表且参数来自左表时，JOIN 会直接报错或语义错误。
-
JOIN要求右表是静态关系，例如INNER JOIN Orders o ON u.Id = o.UserId，右表Orders本身不依赖u的任何计算 -
CROSS APPLY允许右端是动态计算：比如CROSS APPLY dbo.GetCitiesByRegionId(u.RegionId)，u.RegionId在每一行传入函数 - 常见失败写法：
FROM Users u INNER JOIN (SELECT * FROM Cities WHERE RegionId = u.RegionId) c ON 1=1—— 这里u.RegionId在子查询中非法引用，SQL Server 拒绝解析
CROSS APPLY 右侧写子查询时的坑
右侧子查询若含 TOP + ORDER BY，但没建好索引，性能会断崖式下跌——因为每行都触发一次独立排序。
- 错误示例：
CROSS APPLY (SELECT TOP 1 OrderDate FROM Orders WHERE UserId = u.Id ORDER BY CreatedAt DESC)，Orders(UserId, CreatedAt)缺失复合索引 - 执行计划里看“实际行数”是否远大于“估计行数”，有黄色感叹号大概率是缺失索引
- 别用
OFFSET 0 ROWS FETCH NEXT 1 ROWS ONLY替代TOP 1，它无法利用索引 Seek，强制 Sort - 如果右侧只是单行查找，优先改用
LEFT JOIN+ 窗口函数（如ROW_NUMBER()），避免 APPLY 的逐行开销
为什么多语句 TVF 让 CROSS APPLY 变慢
多语句 TVF（MSTVF）被 SQL Server 当作黑盒，无法展开、无法下推谓词、无法重用执行计划——导致左侧每行都调用一次全量扫描。
- 检查函数定义：含
BEGIN ... END、INSERT INTO @t、循环或临时表的，基本是 MSTVF - 替换成内联 TVF：
RETURNS TABLE AS RETURN (SELECT ... WHERE Id = @param)，优化器能把它“内联展开”，像写在主查询里一样走索引 - 用
sys.dm_exec_function_stats查该函数平均逻辑读：total_logical_reads / execution_count > 1000就得重写 - 单独执行函数验证：
SELECT * FROM dbo.SplitTags('A,B,C')如果慢，说明瓶颈在函数内部，不是 APPLY 语法的问题
最易被忽略的一点：CROSS APPLY 的性能问题几乎从不来自 APPLY 本身，而是右侧那个被反复调用的函数或子查询。盯紧执行计划里右侧操作符的“实际行数”和“警告图标”，比调优 APPLY 写法重要十倍。
