gpt4 book ai didi

SQL 字符串比较速度 'like' 与 'patindex'

转载 作者:行者123 更新时间:2023-12-02 07:16:21 24 4
gpt4 key购买 nike

我有一个查询如下(简化)...

SELECT     *
FROM table1 AS a
INNER JOIN table2 AS b ON (a.name LIKE '%' + b.name + '%')

对于我的数据集,执行大约需要 90 秒,因此我一直在寻找加快速度的方法。没有充分的理由,我想我应该尝试 PATINDEX 而不是 LIKE...

SELECT     *
FROM table1 AS a
INNER JOIN table2 AS b ON (PATINDEX('%' + b.name + '%', a.name) > 0)

在同一数据集上,它会在眨眼之间执行并返回相同的结果。

谁能解释一下为什么LIKE比PATINDEX慢这么多?鉴于 LIKE 只是返回 BOOLEAN,而 PATINDEX 返回实际位置,我本以为后者会更慢(如果有的话),或者这只是两个函数编写效率的问题?

好的,这是每个查询的完整内容,后面是它的执行计划。 “#StakeholderNames”只是我要匹配的可能名称的临时表。

我已拉回实时数据并多次运行每个查询。第一个大约需要 17 秒(因此比实时数据库上原来的 90 秒要少一些),第二个不到 1 秒...

SELECT              sh.StakeholderID,
sh.HoldingID,
i.AgencyCommissionImportID,
1

FROM AgencyCommissionImport AS i
INNER JOIN #StakeholderNames AS sn ON REPLACE(REPLACE(i.ClientName,' ',''), ',','') LIKE '%' + sn.Name + '%'
INNER JOIN Holding AS h ON (h.ProviderName = i.Provider) AND (h.HoldingReference = i.PlanNumber)
INNER JOIN StakeholderHolding AS sh ON (sn.StakeholderID = sh.StakeholderID) AND (h.HoldingID = sh.HoldingID)
WHERE i.AgencyCommissionFileID = @AgencyCommissionFileID
AND (i.MatchTypeID = 0)
AND ((i.MatchedHoldingID IS NULL)
OR (i.MatchedStakeholderID IS NULL))

|--Table Insert(OBJECT:([tempdb].[dbo].[#Results]), SET:([#Results].[StakeholderID] = [AttivoGroup_copy].[dbo].[StakeholderHolding].[StakeholderID] as [sh].[StakeholderID],[#Results].[HoldingID] = [AttivoGroup_copy].[dbo].[StakeholderHolding].[HoldingID] as [sh].[HoldingID],[#Results].[AgencyCommissionImportID] = [AttivoGroup_copy].[dbo].[AgencyCommissionImport].[AgencyCommissionImportID] as [i].[AgencyCommissionImportID],[#Results].[MatchTypeID] = [Expr1014],[#Results].[indx] = [Expr1013]))
|--Compute Scalar(DEFINE:([Expr1014]=(1)))
|--Compute Scalar(DEFINE:([Expr1013]=getidentity((1835869607),(2),N'#Results')))
|--Top(ROWCOUNT est 0)
|--Hash Match(Inner Join, HASH:([h].[ProviderName], [h].[HoldingReference])=([i].[Provider], [i].[PlanNumber]), RESIDUAL:([AttivoGroup_copy].[dbo].[Holding].[ProviderName] as [h].[ProviderName]=[AttivoGroup_copy].[dbo].[AgencyCommissionImport].[Provider] as [i].[Provider] AND [AttivoGroup_copy].[dbo].[Holding].[HoldingReference] as [h].[HoldingReference]=[AttivoGroup_copy].[dbo].[AgencyCommissionImport].[PlanNumber] as [i].[PlanNumber] AND [Expr1015] like [Expr1016]))
|--Nested Loops(Inner Join, OUTER REFERENCES:([sh].[HoldingID]))
| |--Nested Loops(Inner Join, OUTER REFERENCES:([sn].[StakeholderID]))
| | |--Compute Scalar(DEFINE:([Expr1016]=('%'+#StakeholderNames.[Name] as [sn].[Name])+'%', [Expr1017]=LikeRangeStart(('%'+#StakeholderNames.[Name] as [sn].[Name])+'%'), [Expr1018]=LikeRangeEnd(('%'+#StakeholderNames.[Name] as [sn].[Name])+'%'), [Expr1019]=LikeRangeInfo(('%'+#StakeholderNames.[Name] as [sn].[Name])+'%')))
| | | |--Table Scan(OBJECT:([tempdb].[dbo].[#StakeholderNames] AS [sn]))
| | |--Clustered Index Seek(OBJECT:([AttivoGroup_copy].[dbo].[StakeholderHolding].[PK_StakeholderHolding] AS [sh]), SEEK:([sh].[StakeholderID]=#StakeholderNames.[StakeholderID] as [sn].[StakeholderID]) ORDERED FORWARD)
| |--Clustered Index Seek(OBJECT:([AttivoGroup_copy].[dbo].[Holding].[PK_Holding] AS [h]), SEEK:([h].[HoldingID]=[AttivoGroup_copy].[dbo].[StakeholderHolding].[HoldingID] as [sh].[HoldingID]) ORDERED FORWARD)
|--Compute Scalar(DEFINE:([Expr1015]=replace(replace([AttivoGroup_copy].[dbo].[AgencyCommissionImport].[ClientName] as [i].[ClientName],' ',''),',','')))
|--Clustered Index Scan(OBJECT:([AttivoGroup_copy].[dbo].[AgencyCommissionImport].[PK_AgencyCommissionImport] AS [i]), WHERE:([AttivoGroup_copy].[dbo].[AgencyCommissionImport].[AgencyCommissionFileID] as [i].[AgencyCommissionFileID]=[@AgencyCommissionFileID] AND [AttivoGroup_copy].[dbo].[AgencyCommissionImport].[MatchTypeID] as [i].[MatchTypeID]=(0) AND ([AttivoGroup_copy].[dbo].[AgencyCommissionImport].[MatchedHoldingID] as [i].[MatchedHoldingID] IS NULL OR [AttivoGroup_copy].[dbo].[AgencyCommissionImport].[MatchedStakeholderID] as [i].[MatchedStakeholderID] IS NULL)))


SELECT sh.StakeholderID,
sh.HoldingID,
i.AgencyCommissionImportID,
1

FROM AgencyCommissionImport AS i
INNER JOIN #StakeholderNames AS sn ON (PATINDEX('%' + sn.Name + '%', REPLACE(REPLACE(i.ClientName,' ',''), ',','')) > 0)
INNER JOIN Holding AS h ON (h.ProviderName = i.Provider) AND (h.HoldingReference = i.PlanNumber)
INNER JOIN StakeholderHolding AS sh ON (sn.StakeholderID = sh.StakeholderID) AND (h.HoldingID = sh.HoldingID)
WHERE i.AgencyCommissionFileID = @AgencyCommissionFileID
AND (i.MatchTypeID = 0)
AND ((i.MatchedHoldingID IS NULL)
OR (i.MatchedStakeholderID IS NULL))

|--Table Insert(OBJECT:([tempdb].[dbo].[#Results]), SET:([#Results].[StakeholderID] = [AttivoGroup_copy].[dbo].[StakeholderHolding].[StakeholderID] as [sh].[StakeholderID],[#Results].[HoldingID] = [AttivoGroup_copy].[dbo].[StakeholderHolding].[HoldingID] as [sh].[HoldingID],[#Results].[AgencyCommissionImportID] = [AttivoGroup_copy].[dbo].[AgencyCommissionImport].[AgencyCommissionImportID] as [i].[AgencyCommissionImportID],[#Results].[MatchTypeID] = [Expr1014],[#Results].[indx] = [Expr1013]))
|--Compute Scalar(DEFINE:([Expr1014]=(1)))
|--Compute Scalar(DEFINE:([Expr1013]=getidentity((1867869721),(2),N'#Results')))
|--Top(ROWCOUNT est 0)
|--Hash Match(Inner Join, HASH:([h].[ProviderName], [h].[HoldingReference])=([i].[Provider], [i].[PlanNumber]), RESIDUAL:([AttivoGroup_copy].[dbo].[Holding].[ProviderName] as [h].[ProviderName]=[AttivoGroup_copy].[dbo].[AgencyCommissionImport].[Provider] as [i].[Provider] AND [AttivoGroup_copy].[dbo].[Holding].[HoldingReference] as [h].[HoldingReference]=[AttivoGroup_copy].[dbo].[AgencyCommissionImport].[PlanNumber] as [i].[PlanNumber] AND patindex([Expr1015],[Expr1016])>(0)))
|--Nested Loops(Inner Join, OUTER REFERENCES:([sh].[HoldingID]))
| |--Nested Loops(Inner Join, OUTER REFERENCES:([sn].[StakeholderID]))
| | |--Compute Scalar(DEFINE:([Expr1015]=('%'+#StakeholderNames.[Name] as [sn].[Name])+'%'))
| | | |--Table Scan(OBJECT:([tempdb].[dbo].[#StakeholderNames] AS [sn]))
| | |--Clustered Index Seek(OBJECT:([AttivoGroup_copy].[dbo].[StakeholderHolding].[PK_StakeholderHolding] AS [sh]), SEEK:([sh].[StakeholderID]=#StakeholderNames.[StakeholderID] as [sn].[StakeholderID]) ORDERED FORWARD)
| |--Clustered Index Seek(OBJECT:([AttivoGroup_copy].[dbo].[Holding].[PK_Holding] AS [h]), SEEK:([h].[HoldingID]=[AttivoGroup_copy].[dbo].[StakeholderHolding].[HoldingID] as [sh].[HoldingID]) ORDERED FORWARD)
|--Compute Scalar(DEFINE:([Expr1016]=replace(replace([AttivoGroup_copy].[dbo].[AgencyCommissionImport].[ClientName] as [i].[ClientName],' ',''),',','')))
|--Clustered Index Scan(OBJECT:([AttivoGroup_copy].[dbo].[AgencyCommissionImport].[PK_AgencyCommissionImport] AS [i]), WHERE:([AttivoGroup_copy].[dbo].[AgencyCommissionImport].[AgencyCommissionFileID] as [i].[AgencyCommissionFileID]=[@AgencyCommissionFileID] AND [AttivoGroup_copy].[dbo].[AgencyCommissionImport].[MatchTypeID] as [i].[MatchTypeID]=(0) AND ([AttivoGroup_copy].[dbo].[AgencyCommissionImport].[MatchedHoldingID] as [i].[MatchedHoldingID] IS NULL OR [AttivoGroup_copy].[dbo].[AgencyCommissionImport].[MatchedStakeholderID] as [i].[MatchedStakeholderID] IS NULL)))

最佳答案

这种可重复的性能差异很可能是由于两个查询的执行计划不同造成的。

让 SQL Server 在每个查询运行时返回实际的执行计划,并比较执行计划。

此外,当您比较两个查询的性能时,运行每个查询两次,并忽略第一次运行的时间。 (第一次查询运行可能包括大量繁重的工作(语句解析和数据库 I/O)。第二次运行将为您提供比其他查询更有效的运行时间。

谁能解释一下为什么 LIKE 比 PATINDEX 慢这么多?

每个查询的执行计划可能会解释其中的差异。

这只是两个函数编写效率的问题吗?

这实际上并不是函数编写效率如何的问题。真正重要的是生成的执行计划。重要的是谓词是否可控制以及优化器是否选择使用可用索引。

<小时/>

[编辑]

在我运行的快速测试中,我发现执行计划存在差异。通过连接谓词中的 LIKE 运算符,该计划在“计算机标量” 操作之后对 table2 包含一个“Table Spool (Lazy Spool)” 操作。使用 PATINDEX 函数,我在计划中没有看到“Table Spool” 操作。但考虑到查询、表、索引和统计信息的差异,我得到的计划可能与您得到的计划有很大不同。

[编辑]

我在两个查询的执行计划输出中看到的唯一区别(除了表达式占位符名称)是对三个内部函数(LikeRangeStartLikeRangeEndLikeRangeInfo 代替对 PATINDEX 函数的一次调用。这些函数似乎是为结果集中的每一行调用的,并且生成的表达式用于扫描嵌套循环中的内表。

因此,看起来对 LIKE 运算符的三个函数调用可能比对 PATINDEX 函数的单个调用更昂贵(从运行时间角度来看)。 (解释计划显示了为嵌套循环连接的外部结果集中的每一行调用的这些函数;对于大量行,即使耗时的微小差异也可以乘以足够多的时间以表现出显着的性能差异。)

<小时/>

在我的系统上运行一些测试用例后,我仍然对您所看到的结果感到困惑。

也许这是对 PATINDEX 函数的调用与对三个内部函数(LikeRangeStart、LikeRangeEnd、LikeRangeInfo)的调用的性能问题。

对于在足够“大”的结果集上执行的结果,耗时的微小差异可能会乘以显着差异。

但实际上,我发现使用 LIKE 运算符的查询比使用 PATINDEX 函数的等效查询执行时间要长得多,这有点令人惊讶。

关于SQL 字符串比较速度 'like' 与 'patindex',我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8052425/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com