内联表值 UDF 能否胜过 SELECT 列列表中的等效标量 UDF？答案

【问题标题】：Can an inline table-valued UDF outperform the equivalent scalar UDF in a SELECT column list?内联表值 UDF 能否胜过 SELECT 列列表中的等效标量 UDF？
【发布时间】：2010-11-08 05:29:09
【问题描述】：

这个问题源于SQLServer: Why avoid Table-Valued User Defined Functions?。我开始在一些 cmets 中提问，而我的 cmets 的回复却跑题了。

这样您就不必阅读整个讨论：我从未听说过用户定义函数 (UDF) 很慢，或者应该避免使用。在上面提到的问题中发布了一些链接，以说明它们很慢。还是没看懂，求个例子。贴了一个例子，性能差异很大。

我不可能是唯一一个没有意识到性能差异如此之大的人。我觉得这个事实应该分成一个新的问题和答案，以提高它被发现的机会。这就是“问题”。请不要关闭，因为我想让回答者有时间发布答案。

当然，其他人也应该发布答案或示例。我会特别感谢任何能帮助我理解为什么性能差异如此之大的东西。

还要注意，我不是在谈论在 WHERE 子句中使用 UDF。我知道这会如何阻止优化器完成其工作。当原始 UDF 是 SELECT 列列表的一部分时，我对性能差异特别感兴趣。

【问题讨论】：

反对票的原因是什么？请说出问题所在，否则我永远不知道如何解决。

标签： sql-server user-defined-functions

【解决方案1】：

为了进行基准测试，让我们创建一个 1M 行的表：

CREATE TABLE dbo.Numbers(n INT NOT NULL PRIMARY KEY)
GO
DECLARE @i INT;
SET @i = 1;
INSERT INTO dbo.Numbers(n) SELECT 1;
WHILE @i<1024000 BEGIN
  INSERT INTO dbo.Numbers(n)
    SELECT n + @i FROM dbo.Numbers;
  SET @i = @i * 2;
END;
GO

运行简单的内联添加：

SELECT COUNT(*) FROM(
SELECT n,n+1 AS ValuePlusOne
FROM  dbo.Numbers
) AS t WHERE ValuePlusOne>0

   CPU time = 15 ms, elapsed time = 122 ms.

(1 row(s) affected)
Table 'Numbers'. Scan count 1, logical reads 3521, physical reads 3, read-ahead reads 3498, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
   CPU time = 406 ms,  elapsed time = 951 ms.

创建一个仅将整数加一的标量 UDF，并运行 1M 次：

CREATE FUNCTION dbo.[AddOne] 
(
        @value int
)
RETURNS int
AS
BEGIN
        DECLARE @Result int
        SELECT @Result = @value + 1
        RETURN @Result
END
GO

SELECT COUNT(*) FROM(
SELECT n,dbo.AddOne(n) AS ValuePlusOne
FROM  dbo.Numbers
) AS t WHERE ValuePlusOne>0

   CPU time = 15 ms, elapsed time = 122 ms.

(1 row(s) affected)
Table 'Numbers'. Scan count 1, logical reads 3521, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
   CPU time = 108313 ms,  elapsed time = 295072 ms.

创建一个内联 UDF，它和添加一样快，然后运行 1M 次：

CREATE FUNCTION dbo.[AddOneInline] 
(
        @value int
)
RETURNS TABLE
AS
RETURN(SELECT @value + 1 AS ValuePlusOne)
GO

SELECT COUNT(*) FROM(
SELECT ValuePlusOne
FROM  dbo.Numbers
CROSS APPLY dbo.[AddOneInline](n)
) AS t WHERE ValuePlusOne>0

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 35 ms.

(1 row(s) affected)
Table 'Numbers'. Scan count 1, logical reads 3521, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
   CPU time = 391 ms,  elapsed time = 403 ms.

标量 UDF 与内联 UDF 的性能差异是显而易见的。

【讨论】：

此测试具有误导性。看一下执行计划无疑会发现内联 UDF 没有被调用 1 M 次，但实际上已经优化到外部查询中。相比之下，标量函数不能如此优化，因为它是一个黑盒子。像其他任何事情一样，每个都有其用途，如果使用得当，就可以达到手头的目的。
@IanC：你是对的，内联调用被展平到查询中，并且每行调用一次标量函数。什么是误导？我关心和谈论的只是性能，我对此的陈述是正确的，不是吗？
我的意思是，不了解各种 UDF 之间差异的人可能会从您的结论中得出与您想要的不同的结论（即正确的结论）。你说的在技术上没有什么不准确的地方。 IMO 帮助他人得出正确的结论很重要:)
由于标量 UDF 不进行数据访问，您应该创建它 WITH SCHEMABINDING。在这种情况下，我没有测试它是否会改变任何东西。

【解决方案2】：

好吧，既然您打开了一个棘手的主题 :-) 我认为我们需要更现实的例子，并避免陷入陷阱。看起来太做作的例子总是让我怀疑。因此，我稍微重新安排了查询，直接标量 UDF 优于查询。不要相信 - 试试看 - 这是在 SQL 2k8 上，在 2k8 服务器标准下的开发盒上。

到目前为止，我们所学到的只是在 WHERE 子句中使用计算列和等效项是不好的。该查询在 WHERE 子句中使用标量函数，同时假装它在选择中。

SELECT COUNT(*) FROM( 
SELECT n as X,n+1 AS ValuePlusOne 
FROM  dbo.Numbers 
) AS t WHERE X>0

表格“数字”。扫描计数 1，逻辑读取 3521，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。

SQL Server 执行时间： CPU 时间 = 234 毫秒，经过的时间 = 228 毫秒。

SELECT COUNT(*) FROM( 
SELECT n as X ,dbo.AddOne(n) AS ValuePlusOne 
FROM  dbo.Numbers 
) AS t WHERE X>0

表格“数字”。扫描计数 1，逻辑读取 3521，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。

SQL Server 执行时间： CPU 时间 = 202 毫秒，经过的时间 = 215 毫秒。

那么，既然我们已经解决了这个问题，那么一些真实的信息和实际的用例怎么样？

我将提供 2 个供辩论 :-) 但请记住不要人为的陷阱。 TVF 和标量 UDF 只是调用它以方便地获取值，然后在查询中用作值或连接 - 没有人计算任何东西。有人可以构建一个表格或说明病理数据必须如何才能看到 LCID1 和 LCID2 之间的性能差异吗？

CREATE FUNCTION [PublishingCulture]  ( @XLanguage int,
                                 @XLocale int 
) RETURNS TABLE 
AS
RETURN 
(
    select TOP 1 * from [Culture] C
    where ((C.XLang = @XLanguage and C.XLoc = @XLocale)
      or   (C.XLang = @XLanguage and C.XLoc  = 0)
      or   (C.XLang = 0 and C.XLoc = @XLocale)
      or   (C.XLang = 0 and C.XLoc = 0))
)

CREATE FUNCTION [MyLCID1] ( @XLanguage int,
                      @XLocale int )
RETURNS TABLE
AS
     RETURN ( SELECT LCID from dbo.PublishingCulture(@XLanguage, @XLocale) )

CREATE FUNCTION [MyLCID2] ( @XLanguage int,
                      @XLocale int )
RETURNS int
AS
BEGIN
    RETURN ( SELECT LCID from dbo.PublishingCulture(@XLanguage, @XLocale) )
END

select * from 
   (select Row_number() OVER(order by StartDate) as RN, Message 
    from [Ticker] as T
    join dbo.MyLCID1(@XLanguage, @XLocale) as L on T.LCID = L.LCID
    where
      Getutcdate() BETWEEN StartDate AND EndDate
   ) AS T
where RN BETWEEN @StartIndex AND (@StartIndex + @MaxItems -1)

select * from 
   (select Row_number() OVER(order by StartDate) as RN, Message 
    from [Ticker] as T
    where
        LCID = dbo.PubLCID1(@XLanguage, @XLocale) AND
   Getutcdate() BETWEEN StartDate AND EndDate
   ) AS T
where RN BETWEEN @StartIndex AND (@StartIndex + @MaxItems -1)

[Culture] 在 XLang、Xloc 上有 PK，[Ticker] 在 LCID、Id（Id 是人工的）上有 PK，在 StartDare、EndDate、LCID 上有 IX —— 几行就可以接近真实的东西.

【讨论】：