奇怪的性能问题:行内用户定义函数中的公共表达式

12

这里有一个对于 SQL 程序员的难题 - 有谁能够想出第一种函数表现良好,而第二种运行极其缓慢的原因?

函数 A - 典型情况下在约 5 毫秒内完成

CREATE FUNCTION dbo.GoodFunction
(
    @IDs UniqueIntTable READONLY
)
RETURNS TABLE
AS RETURN
    SELECT p.ID, p.Node, p.Name, p.Level
    FROM
    (
        SELECT DISTINCT a.Ancestor AS Node
        FROM Hierarchy h
        CROSS APPLY dbo.GetAncestors(h.Node.GetAncestor(1)) a
        WHERE h.ID IN (SELECT Value FROM @IDs)
    ) np
    INNER JOIN Hierarchy p
    ON p.Node = np.Node

函数B - 运行极慢 - 我放弃了,五分钟都等不起

CREATE FUNCTION dbo.BadFunction
(
    @IDs UniqueIntTable READONLY
)
RETURNS TABLE
AS RETURN
    WITH Ancestors_CTE AS
    (
        SELECT DISTINCT a.Ancestor AS Node
        FROM Hierarchy c
        CROSS APPLY dbo.GetAncestors(c.Node.GetAncestor(1)) a
        WHERE c.ID IN (SELECT Value FROM @IDs)
    )
    SELECT p.ID, p.Node, p.Name, p.Level
    FROM Ancestors_CTE ac
    INNER JOIN Hierarchy p
    ON p.Node = ac.Node
我将在下面解释这个函数的作用,但在此之前,我想指出,我认为这不重要,因为据我所知,这两个函数完全相同!唯一的区别是一个使用了CTE,另一个使用了子查询;A中子查询的内容和B中CTE的内容是相同的
如果有人觉得这很重要:该函数的目的仅是选择任意数量位置在层次结构中的所有可能的祖先(父母、祖父母等)。Node列是hierarchyiddbo.GetAncestors是一个CLR函数,它简单地沿着路径向上遍历,不做任何数据访问。 UniqueIntTable是其名称的含义 - 它是一个用户定义的表类型,有一列Value int NOT NULL PRIMARY KEY。所有应该索引的内容都已索引 - 函数A的执行计划基本上只是两个索引查找和一个哈希匹配,就像函数B应该做的那样。
甚至有些更奇怪的问题:
  • 我甚至不能为使用函数B的简单查询获得预估的执行计划。看起来性能问题几乎与这个看起来简单的函数的编译有关。

  • 如果我将函数B的"主体"取出来,只是将其插入到一个内联查询中,它会像函数A一样正常运行,性能相同。所以这似乎只是一个在UDF 内部使用CTE时才会遇到的问题,或者反过来,只有使用CTE的UDF才会遇到这个问题。

  • 尝试运行B时测试机器上一个核心的CPU使用率飙升到100%。看起来没有太多I/O。

我想要把它简单地归咎于SQL Server的一个错误,并使用版本A,但我总是尽力遵循第一条规则("选择不是错误的"),并且我担心函数A的良好结果在某种程度上是一次局部性的巧合,在另一台服务器上它也会像B一样"失败"。
有什么想法吗?
[SqlFunction(FillRowMethodName = "FillAncestor", 
    TableDefinition = "Ancestor hierarchyid", IsDeterministic = true,
    IsPrecise = true, DataAccess = DataAccessKind.None)]
public static IEnumerable GetAncestors(SqlHierarchyId h)
{
    while (!h.IsNull)
    {
        yield return h;
        h = h.GetAncestor(1);
    }
}

模式创建

BEGIN TRAN

CREATE TABLE Hierarchy
(
    ID int NOT NULL IDENTITY(1, 1)
        CONSTRAINT PK_Hierarchy PRIMARY KEY CLUSTERED,
    Node hierarchyid NOT NULL,
    [Level] as Node.GetLevel(),
    Name varchar(50) NOT NULL
)

CREATE INDEX IX_Hierarchy_Node
ON Hierarchy (Node)
INCLUDE (Name)

CREATE INDEX IX_Hierarchy_NodeBF
ON Hierarchy ([Level], Node)

GO

INSERT Hierarchy (Node, Name)
    SELECT CAST('/1/' AS hierarchyid), 'Alice' UNION ALL
    SELECT CAST('/1/1/' AS hierarchyid), 'Bob' UNION ALL
    SELECT CAST('/1/1/1/' AS hierarchyid), 'Charles' UNION ALL
    SELECT CAST('/1/1/2/' AS hierarchyid), 'Dave' UNION ALL
    SELECT CAST('/1/1/3/' AS hierarchyid), 'Ellen' UNION ALL
    SELECT CAST('/1/2/' AS hierarchyid), 'Fred' UNION ALL
    SELECT CAST('/1/3/' AS hierarchyid), 'Graham' UNION ALL
    SELECT CAST('/1/3/1/' AS hierarchyid), 'Harold' UNION ALL
    SELECT CAST('/1/3/2/' AS hierarchyid), 'Isabelle' UNION ALL
    SELECT CAST('/1/4/' AS hierarchyid), 'John' UNION ALL
    SELECT CAST('/2/' AS hierarchyid), 'Karen' UNION ALL
    SELECT CAST('/2/1/' AS hierarchyid), 'Liam' UNION ALL
    SELECT CAST('/2/2/' AS hierarchyid), 'Mary' UNION ALL
    SELECT CAST('/2/2/1/' AS hierarchyid), 'Nigel' UNION ALL
    SELECT CAST('/2/2/2/' AS hierarchyid), 'Oliver' UNION ALL
    SELECT CAST('/2/3/' AS hierarchyid), 'Peter' UNION ALL
    SELECT CAST('/2/3/1/' AS hierarchyid), 'Quinn'

GO

CREATE TYPE UniqueIntTable AS TABLE 
(
    Value int NOT NULL,
    PRIMARY KEY (Value)
)

GO

COMMIT

GO

上述的代码/脚本可用于创建CLR函数/DB架构;在原始版本中使用相同的GoodFunctionBadFunction脚本。


我的错误。我一开始没有注意到你在使用SQL 2008。评论已撤回 :) - Tom H
啊哈!所以我打赌SQL Server创建执行计划的方式有问题。你是否尝试在另一台服务器(如开发服务器)上以及从另一台工作站上进行完全相同的操作?这也可能是其中一个补丁级别存在问题。 - Brent Ozar
无论如何,我猜测一个明确的答案正在浮现,那就是唯一的确定答案将来自于微软的SQL Server团队。看看他们有什么话要说会很有趣。 - Aaronaught
@RBarryYoung:我理解你想表达的意思,但这只是在估算执行计划时发生的,实际上根本没有运行查询,即使运行了,特征也是毫无意义的。花费数小时来运行一个15行的查询,让CPU在整个过程中变得不可用?我不这么认为。即使是“默认查询计划”——这是你提出的术语,而不是我——在执行时也不可能导致这些影响。 - Aaronaught
1
好的,谁给这个问题点了踩?说真的!这个问题还能更清晰和具体吗? - Aaronaught
显示剩余14条评论
5个回答

10

哈哈,试试这个:

IF OBJECT_ID('_HappyFunction' ) IS NOT NULL DROP FUNCTION _HappyFunction
IF OBJECT_ID('_SadFunction'   ) IS NOT NULL DROP FUNCTION _SadFunction
IF TYPE_ID  ('_UniqueIntTable') IS NOT NULL DROP TYPE _UniqueIntTable
GO

CREATE TYPE _UniqueIntTable AS TABLE (Value int NOT NULL PRIMARY KEY)
GO

CREATE FUNCTION _HappyFunction (@IDs _UniqueIntTable READONLY)
RETURNS TABLE AS RETURN
  SELECT Value FROM @IDs
GO

CREATE FUNCTION _SadFunction (@IDs _UniqueIntTable READONLY)
RETURNS TABLE AS RETURN 
  WITH CTE AS (SELECT Value FROM @IDs)
  SELECT Value FROM CTE
GO

-- this will return an empty record set
DECLARE @IDs _UniqueIntTable 
SELECT * FROM _HappyFunction(@IDs)
GO

-- this will hang
DECLARE @IDs _UniqueIntTable 
SELECT * FROM _SadFunction(@IDs)
GO

谁会猜到呢?


这太疯狂了!这里到底发生了什么事? - Aaronaught
现在它已经正式发布在MS Connect上了:https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=527843。我将此答案标记为已接受的答案,因为它从方程中消除了几个变量(`hierarchyid`、`CROSS APPLY`和模式),简化了重现步骤,并使提交案例更加容易。再次感谢! - Aaronaught

2
我已经在SQL 2008 SP1上复制了这种行为,用SQL UDF替换了CLF UDF dbo.GetAncestors。我尝试了表值函数和内联函数,但没有任何区别。
我还不知道发生了什么,但为了方便其他人,我将包含我的定义如下。
-- try a recursive inline UDF...
CREATE FUNCTION dbo.GetAncestors(@hierarchyid hierarchyid)
RETURNS TABLE AS RETURN (
WITH recurse AS (
    SELECT @hierarchyid AS Ancestor
    WHERE @hierarchyid IS NOT NULL
    UNION ALL
    SELECT Ancestor.GetAncestor(1) FROM recurse
    WHERE Ancestor.GetAncestor(1) IS NOT NULL
    )
SELECT * FROM recurse
)

-- ...or a table-valued UDF, it makes no difference
CREATE FUNCTION dbo.GetAncestors(@hierarchyid hierarchyid)
RETURNS @return TABLE (Ancestor hierarchyid) 
AS BEGIN
    WHILE @hierarchyid IS NOT NULL BEGIN
        INSERT @return (Ancestor)
        VALUES (@hierarchyid)
        SET @hierarchyid = @hierarchyid.GetAncestor(1)
    END             
    RETURN
END

选择上面的一个定义,然后运行以下代码来观察它的卡顿现象:
DECLARE @IDs UniqueIntTable 
INSERT @IDs SELECT ID FROM Hierarchy
RAISERROR('we have inserted %i rows.',-1,-1,@@ROWCOUNT) WITH NOWAIT
SELECT * FROM dbo.GoodFunction(@IDs) a
RAISERROR('we have returned %i rows.',-1,-1,@@ROWCOUNT) WITH NOWAIT
GO

DECLARE @IDs UniqueIntTable 
INSERT @IDs SELECT ID FROM Hierarchy
RAISERROR('we have inserted %i rows.',-1,-1,@@ROWCOUNT) WITH NOWAIT
SELECT * FROM dbo.BadFunction(@IDs) a
RAISERROR('we have returned %i rows.',-1,-1,@@ROWCOUNT) WITH NOWAIT
GO

第二批次甚至没有开始。它在解析阶段通过了,但似乎在绑定和优化之间迷失了方向。

两个函数的主体编译成完全相同的执行计划,在函数包装器之外:

SET SHOWPLAN_TEXT ON
GO
DECLARE @IDs UniqueIntTable 
INSERT @IDs SELECT ID FROM Hierarchy
SELECT p.ID, p.Node, p.Name, p.[Level]
FROM
(
    SELECT DISTINCT a.Ancestor AS Node
    FROM Hierarchy c 
    CROSS APPLY dbo.GetAncestors_IF(c.Node.GetAncestor(1)) a
    WHERE c.ID IN (SELECT Value FROM @IDs)
) np
INNER JOIN Hierarchy p
ON p.Node = np.Node

;WITH Ancestors_CTE AS
(
    SELECT DISTINCT a.Ancestor AS Node
    FROM Hierarchy c
    CROSS APPLY dbo.GetAncestors_IF(c.Node.GetAncestor(1)) a
    WHERE c.ID IN (SELECT Value FROM @IDs)
)
SELECT p.ID, p.Node, p.Name, p.[Level]
FROM Ancestors_CTE ac
INNER JOIN Hierarchy p
ON p.Node = ac.Node


-- both return this:

    |--Nested Loops(Inner Join, OUTER REFERENCES:([p].[Node]))
         |--Compute Scalar(DEFINE:([p].[Level]=[Scratch].[dbo].[Hierarchy].[Level] as [p].[Level]))
         |    |--Compute Scalar(DEFINE:([p].[Level]=[Scratch].[dbo].[Hierarchy].[Node] as [p].[Node].GetLevel()))
         |         |--Index Scan(OBJECT:([Scratch].[dbo].[Hierarchy].[IX_Hierarchy_Node] AS [p]))
         |--Top(TOP EXPRESSION:((1)))
              |--Filter(WHERE:([Recr1005]=[Scratch].[dbo].[Hierarchy].[Node] as [p].[Node]))
                   |--Nested Loops(Inner Join, OUTER REFERENCES:([c].[Node]))
                        |--Nested Loops(Inner Join, OUTER REFERENCES:([Value]))
                        |    |--Clustered Index Scan(OBJECT:(@IDs))
                        |    |--Clustered Index Seek(OBJECT:([Scratch].[dbo].[Hierarchy].[PK_Hierarchy] AS [c]), SEEK:([c].[ID]=[Value]) ORDERED FORWARD)
                        |--Index Spool(WITH STACK)
                             |--Concatenation
                                  |--Compute Scalar(DEFINE:([Expr1011]=(0)))
                                  |    |--Constant Scan(VALUES:(([Scratch].[dbo].[Hierarchy].[Node] as [c].[Node].GetAncestor((1)))))
                                  |--Assert(WHERE:(CASE WHEN [Expr1013]>(100) THEN (0) ELSE NULL END))
                                       |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1013], [Recr1003]))
                                            |--Compute Scalar(DEFINE:([Expr1013]=[Expr1012]+(1)))
                                            |    |--Table Spool(WITH STACK)
                                            |--Compute Scalar(DEFINE:([Expr1004]=[Recr1003].GetAncestor((1))))
                                                 |--Filter(WHERE:(STARTUP EXPR([Recr1003].GetAncestor((1)) IS NOT NULL)))
                                                      |--Constant Scan

非常有趣。在微软连接(Microsoft Connect)提交一个错误报告,让他们告诉你发生了什么。


有趣的是,即使没有CLR函数也可以重现这个问题,如果需要提交错误报告,这将使事情变得更加容易。感谢您耐心地处理这个问题,并确认这不仅仅是优化器放弃的情况。 - Aaronaught

1

这只是一种猜测,也许与优化器如何进行最佳执行计划的良好猜测有关,但并没有进行详尽的搜索。

所以,查询执行的工作方式如下:

解析 -> 绑定 -> 优化 -> 执行

您两个查询的解析树肯定不同。绑定树可能不同。我不知道绑定阶段足够说明,但假设绑定树是不同的,则可能需要不同数量的转换才能将A和B绑定树转换为相同的执行计划。

如果需要两个额外的转换将查询B转换为约5毫秒的计划,优化器可能会在发现之前说“够好了”。而对于查询A,约5毫秒的计划可能只是搜索成本阈值内部。


1
我认为这是任何人但微软能给出的最好答案。如果在优化过程中失败,它仍然可以执行,因为绑定阶段产生的解析树是可执行的。但是,1)性能很差,因为它未经优化,2)它是语法和顺序敏感的,因为优化器会处理这个问题,3)没有真正的查询计划,因为查询计划包括成本,而优化器也会处理这个问题。请注意,这三个症状都在OP的问题中明显。 - RBarryYoung
正如我在一些问题评论中提到的那样,它不能仅仅是因为估计的计划根本没有返回而选择了低效的计划,在一个非常小的表上,即使三重笛卡尔积也只需要不到一秒钟。尽管我希望它能够解释,但“懒惰优化器”的解释似乎站不住脚。 - Aaronaught
被选择的不是低效的计划。而是没有被选择的计划,必须使用原始解析树。(请参见我对您问题的评论,上面) - RBarryYoung

0
在第一条语句中,你的连接是
np INNER JOIN Hierarchy p
    ON p.Node = np.Node

你的第二个语句是

Ancestors_CTE a
INNER JOIN Hierarchy p
ON p.Node = a.Node

然而,在CT中,a也被用作dbo.GetAncestors(c.Node.GetAncestor(1))的别名。尝试将Ancestors_CTE a替换为例如Ancestor_CTE acte,以确保优化器不会因别名的双重使用而混淆。

话虽如此,我不确定SQL Server在创建CTE时是否能够应用正确的索引。我以前遇到过这样的问题,并且使用表变量取得了巨大的成功。


不幸的是,那不是它的问题 - SQL Server 没有问题可以解决它,但你很敏锐,我已经更新了问题以明确这一点。 - Aaronaught

-1

据我所知,在批处理中使用CTE时,必须以“;”结束语句。这与WITH子句的解释有关。请尝试以下操作:

IF OBJECT_ID('_HappyFunction' ) IS NOT NULL DROP FUNCTION _HappyFunction  
IF OBJECT_ID('_NowHappyFunction') IS NOT NULL DROP FUNCTION _NowHappyFunction  
IF TYPE_ID  ('_UniqueIntTable') IS NOT NULL DROP TYPE _UniqueIntTable  
GO  

CREATE TYPE _UniqueIntTable AS TABLE (Value int NOT NULL PRIMARY KEY)  
GO  

CREATE FUNCTION _HappyFunction (@IDs _UniqueIntTable READONLY)  
RETURNS TABLE AS RETURN  
  SELECT Value FROM @IDs  
GO  

CREATE FUNCTION _NowHappyFunction (@IDs _UniqueIntTable READONLY)  
RETURNS @Table TABLE
(
Value INT
)
BEGIN
  ;WITH CTE AS (SELECT Value FROM @IDs)
  INSERT INTO @Table
  SELECT Value FROM CTE
  RETURN
END
GO

-- this will return an empty record set  
DECLARE @IDs _UniqueIntTable   
SELECT * FROM _HappyFunction(@IDs)  
GO  

-- this will no longer hang and will also return an empty record set 
DECLARE @IDs _UniqueIntTable   
SELECT * FROM _NowHappyFunction(@IDs)  
GO 

那不会执行。WITH语句前面的分号会导致错误,阻止您创建函数。 - NotMe
1
已更正语法并将内联函数更改为多行语句函数。现在可以编译。 - Shane Collinsworth

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接