如何优化SQL Server中的Cross Apply查询_提升表值函数关联效率-SQL-PHP中文网

cross apply 变慢主因是右侧多语句tvf未内联导致逐行执行、无法下推谓词及索引失效；应改用内联tvf、添加覆盖索引并检查执行计划与函数统计信息。

如何优化sql server中的cross apply查询_提升表值函数关联效率

CROSS APPLY 查询慢，大概率不是语法问题，而是右侧表值函数（TVF）没走索引或被当成多行执行器反复调用。

为什么 CROSS APPLY 会变慢？

核心在于“逐行调用”这个特性：SQL Server 对左侧每一行，都重新执行一次右侧的 SELECT 或表值函数。如果右侧是未内联的多语句 TVF（CREATE FUNCTION ... RETURNS @t TABLE (...) AS BEGIN ... END），它会被当作黑盒，无法展开优化，且每次调用都生成独立执行计划 —— 这比 JOIN 慢一个数量级。

多语句 TVF 无法下推谓词，WHERE 条件进不去函数体内部
即使函数里有 WHERE id = @param，SQL Server 仍可能对全表扫描后再过滤
右侧子查询若含 TOP + ORDER BY，但没建好索引，每行都触发一次排序
左侧数据量大（比如 10 万行），右侧哪怕平均 10ms，总耗时也超 16 分钟

怎么判断右侧是不是“坏 TVF”？

看执行计划里右侧操作符的“实际行数”和“估计行数”是否严重偏差，以及是否有黄色感叹号（缺失索引）或红色叉号（隐式转换）。更直接的方法是单独执行该 TVF：

SELECT * FROM dbo.SplitTags('A,B,C')

如果返回慢、或执行计划显示“Table Scan”或“Clustered Index Scan”，基本可以确认问题出在它身上。

用 sys.dm_exec_function_stats 查看该函数缓存计划的平均 CPU/逻辑读：total_logical_reads / execution_count 超过 1000 就要警惕
检查函数定义：含 BEGIN ... END、INSERT INTO @t、循环或临时表的，基本是多语句 TVF，应重写为内联 TVF
内联 TVF 长这样：RETURNS TABLE AS RETURN (SELECT ...)，它会被优化器展开，能用上索引

如何把慢 Cross Apply 变快？

优先替换右侧为内联表值函数，再辅以索引和参数化。别试图“优化 APPLY 本身”——它的机制就是逐行，优化点永远在右侧。

把多语句 TVF 改成内联 TVF：去掉 BEGIN/END 和表变量，直接 RETURN (SELECT ...)
确保内联 TVF 中的 WHERE 条件列有索引，特别是被左侧传入的参数列（如 WHERE OrderID = @order_id）
如果右侧是子查询，把 ORDER BY ... OFFSET 0 ROWS FETCH NEXT 3 ROWS ONLY 改成带覆盖索引的 TOP 3，并确认排序字段已索引
避免在 CROSS APPLY 右侧调用标量函数（如 dbo.CalcValue(x)），它会在每行重复计算；改用计算列 + 索引，或提前在左侧 JOIN 前算好

容易被忽略的性能陷阱

很多人以为加了索引就万事大吉，但 CROSS APPLY 的右侧执行环境很特殊：它不继承外部查询的参数嗅探上下文，尤其在存储过程中，第一次编译的参数值可能让计划完全失效。

用 OPTION (RECOMPILE) 强制每次重编译（适合参数变化大、数据分布不均的场景）
避免在 TVF 内部用 GETDATE() 或 NEWID()，它们会让函数无法内联
如果左侧是大表分页（如 OFFSET 10000 ROWS），CROSS APPLY 会先取全部左侧行再关联，此时应把分页逻辑移到最外层，而不是包在 APPLY 里
注意统计信息陈旧：右侧表若长期没更新统计信息，优化器可能误判行数，导致选错连接方式（如 Nested Loop 而非 Hash Join）

真正卡住性能的，往往不是 APPLY 关键字本身，而是右侧那个看似无害的函数——它像一个黑箱，把索引、参数、统计信息全挡在外面。动手前，先用执行计划和 sys.dm_exec_function_stats 把它打开看看。