内联表重视 UDF 性能

Question

我使用的是 SQL Server 2008R2。我编写了以下表值 UDF，它接受标量值 this 或 that 或两者都作为参数，并返回包含列 ID、this 和 that 的表。当我从复杂查询中调用此函数时，我看到了糟糕的性能，但在简单查询中调用它时却没有。我想知道是否有人对我正在做的事情有任何想法，这会减慢速度。函数定义如下：

CREATE function dbo.fn_getThisThat (@this nvarchar(255), @that nvarchar(255))
RETURNS TABLE
RETURN

SELECT These.this, Those.that, COALESCE(These.ID, Those.ID) as ID
FROM 
    (
    SELECT col1 as ‘this’, value1, value2, ID
    FROM (
        SELECT t1.col1, t1.col2, t1.col3, t2.col1
        FROM t1
        JOIN t2
            ON t1.col1 = t2.col1
        WHERE t2.col2 = ‘this’
        AND t1.col1 in (‘value1’, ‘value2’)
        ) SOURCE
    PIVOT (
        MAX(t1.col3) FOR t1.col1 in (value1, value2)
        ) AS pvt
    ) These
JOIN
    (
    SELECT t1.col1, t1.col2, t2.col1, t3.ID
    FROM t3
    JOIN t1
        ON t3.col1 = t1.col1
    JOIN t2
        ON t2.col1 = t1.col1
    WHERE t3.col3 = ‘value3’
    AND t1.col3 = ‘value1’
    AND t2.col3 = ‘value2’
    ) Those
WHERE that = @that
OR this = @this

在传递标量参数时，以下语句的处理速度非常快（

SELECT * FROM dbo.fn_getThisThat(scalarValue, null)

或者在一个相对简单的查询中，例如：

SELECT t1.col1, t1.col2, fn.This
FROM t1
CROSS APPLY dbo.fn_getThisThat(t1.col3, null)

...但是当在这样的更复杂的查询中调用时（在伪代码中：如果信息不足，请告诉我），它会滞后（从 ~1 秒到 ~2:30 秒的处理时间）：

DECLARE @table (a, b, c)
INSERT @table (a, b, c)
SELECT (values)

SELECT t1.c1, t1.c2, t1.c3
FROM
    (
    SELECT a.c1, COUNT(fn.That) as c2, COUNT(a.c2) as c3
    FROM a
    JOIN b ON (join terms)
    CROSS APPLY dbo.fn_getThisThat(a.c2, null) fn
    WHERE a.c1 IN (SELECT a FROM @table)
    GROUP BY a.c1
    ) t1

有人对我在第二个查询中降低速度的方法有什么建议吗？我将函数更改为接受数组而不是标量参数，但这消除了我交叉应用的能力（在最后一个代码片段中）。据我从查询分析器可以看出，性能损失来自我的函数的交叉应用。我以为我不会遇到 RBAR，因为我的 UDF 不是多语句，但也许我错了……？

编辑： 还有一件事：查询执行计划显示函数本身对批处理的贡献只有 2%；较大的查询贡献了 98%，但其大部分成本来自索引搜索和表扫描，而不是来自并行性。这让我觉得，也许函数调用并不是查询迟缓的原因，而是一些涉及的表缺乏索引（不幸的是，我对添加指数。）。我在没有调用函数的情况下运行了查询，表扫描和索引搜索仍然显示很高，但查询在大约 8 秒内完成。那么，我们回到函数...？

Answer 1

您可能希望更改您的 UDF 以在任何地方正确使用由两部分组成的表名，以便您可以向其中添加 SCHEMABINDING 子句。见Improving query plans with the SCHEMABINDING option on T-SQL UDFs。

Answer 2

来自 MSDN 文章 Apply (MSDN - Apply)：

“APPLY 运算符允许您为查询的外部表表达式返回的每一行调用表值函数。”

您的示例显示了分组依据。是否可以在对行进行分组后而不是在该特定查询中调用您的函数？这将减少必须调用该函数的行数。

如果做不到这一点，我的另一个建议是通过优化那里的查询来尽可能地提高函数本身的性能。你可以使每毫秒快一点，它就会加起来。

Answer 3

正如已经指出的，对于外部查询中的每一行都会调用 CROSS APPLY。所以，这里的关键问题是从多少行返回：

DECLARE @table (a, b, c)
INSERT @table (a, b, c)
SELECT (values)

SELECT t1.c1, t1.c2, t1.c3
FROM
    (
    SELECT a.c1
    FROM a
    JOIN b ON (join terms)
    WHERE a.c1 IN (SELECT a FROM @table)
    ) t1

这是向您的 TVF 发出的调用次数。如果（这是一个很大的假设）对于任何 a.c2 值，TVF 具有相似的执行时间，那么相关的性能比较是您的函数的奇异执行时间 * 从上面的查询返回的行。

由于原始查询的混淆/概括，很难确定，但我怀疑您的 TVF 可能会被消除，并且逻辑内联到父查询。如果可行，这可能会为您带来最佳性能。

Answer 4

我认为最好的办法是在 SSMS 中运行它并检查你的执行计划。由于这是一个内联表值 UDF，因此优化器会将其合并到执行计划中，您应该能够看到哪里出了问题。

我没有太多在 CROSS APPLY 情况下使用 PIVOT 子查询的经验——这让我觉得这可能是个问题。但执行计划肯定会告诉你。

Answer 5

到目前为止，我已经能够将性能从 ~2:30 提高到 ~0:17。它更好，但仍然不理想。我做了以下事情：

• 为我的电视 udf 添加了模式绑定（谢谢你，Remus！）。这有帮助，但对性能的影响似乎比以下情况要小。

• 重组主查询以加入 @table 而不是在子查询中引用它：这似乎最有帮助，而且似乎大部分性能提升都来自于此。

我认为我剩下的滞后是由于我重击的大表上缺少一些索引，但没有添加它们的能力，我不确定我能做什么 atm。根据查询分析器的报告，我已将并行性的成本降低到 0%，因此我认为在函数调用方面我已尽我所能。

谢谢大家！