SQL Server中表值函数建表关联与子查询的性能对比

1. 表值函数的成本计算规则 #

SQL Server对表值函数的成本计算分两种情况：

• 内联表值函数（Inline TVF）：这类函数会被SQL Server直接展开到主查询的执行计划中，函数内部的所有计算逻辑（比如表扫描、聚合、过滤）都会被完整计入整体执行成本，和直接写子查询的逻辑等价。判断方式：函数定义是RETURNS TABLE AS RETURN (...)，没有BEGIN/END块。
• 多语句表值函数（Multi-statement TVF）：这类函数的执行计划不会被展开到主查询计划里，主计划仅显示调用函数的开销，函数内部的计算逻辑成本不会被统计到主计划中，这时候预估成本会被明显低估。判断方式：函数定义包含RETURNS @table TABLE (...)，且有BEGIN/END块包裹的逻辑。

2. 主键索引对关联成本的影响 #

你提到函数返回的表带有主键索引，这会直接降低关联操作的开销：

• 主键默认是唯一聚集索引，SQL Server在关联时可以选择更高效的嵌套循环连接或合并连接，避免哈希连接带来的高CPU开销。
• 索引能让SQL Server快速定位匹配的数据行，大幅减少逻辑读、物理读的数量，这部分优化会直接体现在执行计划的成本估算里。
  如果你的子查询返回的是无索引的临时结果集，关联时SQL Server只能做全表扫描或哈希连接，成本自然会比带主键索引的函数返回表高。

3. 验证函数成本是否完整计入的方法 #

• 查看实际执行计划：如果是内联TVF，实际计划里能看到函数内部的表访问逻辑，说明成本已完整计入；如果是多语句TVF，计划里只会显示一个“表值函数调用”的节点，看不到内部逻辑。
• 单独执行函数：运行SELECT * FROM departmentSummary()，查看它的单独执行计划，对比这个成本和主查询中函数调用的成本。如果主计划里的成本远低于单独执行的成本，说明主计划没包含函数内部的计算开销。
• 查看实际运行统计：执行SET STATISTICS IO, TIME ON后分别运行两个查询，对比逻辑读、物理读和CPU时间。执行计划的预估成本可能有偏差，实际运行的统计数据更能反映真实效率。

内容的提问来源于stack exchange，提问作者Kevin Smeeks