我的查询如下(简化)......
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)))
答案 0 :(得分:4)
这种可重复的性能差异很可能是由于两个查询的执行计划存在差异。
让SQL Server在运行每个查询时返回实际的执行计划,并比较执行计划。
此外,运行每个查询两次,并在比较两个查询的性能时丢弃第一次运行的时间。 (第一次查询运行可能包括很多繁重的工作(语句解析和数据库i / o)。第二次运行会给你一个比另一个查询更有效的经过时间。
有谁可以解释为什么LIKE比PATINDEX慢得多?
每个查询的执行计划可能会解释其中的差异。
这仅仅是两个函数编写效率的问题吗?
这并不是函数编写效率的问题。真正重要的是生成的执行计划。重要的是谓词是否可以被判断以及优化器是否选择使用可用索引。
[编辑]
在我跑的快速测试中,我发现执行计划存在差异。使用连接谓词中的LIKE运算符,计划在"Table Spool (Lazy Spool)"
操作之后在table2上包含"Computer Scalar"
操作。使用PATINDEX函数,我在计划中看不到"Table Spool"
操作。但鉴于查询,表格,索引和统计数据存在差异,我得到的计划可能与您获得的计划有很大不同。
[编辑]
我在两个查询的执行计划输出中看到的唯一区别(除了表达式占位符名称)是对三个内部函数(LikeRangeStart
,LikeRangeEnd
和{{1}的调用代替对LikeRangeInfo
函数的一次调用。这些函数似乎是为结果集中的每一行调用的,结果表达式用于在嵌套循环中扫描内部表。
因此,看起来好像PATINDEX
运算符的三个函数调用可能比单LIKE
函数调用更昂贵(经过时间)。 (解释计划显示了为嵌套循环连接的外部结果集中的每一行调用的那些函数;对于大量行,即使经过时间的微小差异也可以乘以足够的次数以显示显着的性能差异。)
在我的系统上运行一些测试用例之后,我仍然对你看到的结果感到困惑。
对于PATINDEX函数的调用与对三个内部函数(LikeRangeStart,LikeRangeEnd,LikeRangeInfo)的调用的性能,可能存在问题。
对于在“大”足够的结果集上执行的那些,可能会将经过时间的微小差异乘以显着差异。
但实际上我发现使用LIKE运算符的查询比使用PATINDEX函数的等效查询要花费更长的时间更令人惊讶。
答案 1 :(得分:2)
我完全不相信这篇论文是LikeRangeStart
,LikeRangeEnd
,LikeRangeInfo
函数的额外开销,它们负责时间差异。
它根本不可重复(至少在我的测试,默认校对等)。当我尝试以下
SET STATISTICS IO OFF;
SET STATISTICS TIME OFF;
DECLARE @T TABLE (name sysname )
INSERT INTO @T
SELECT TOP 2500 name + '...' +
CAST(ROW_NUMBER() OVER (ORDER BY (SELECT 0)) AS VARCHAR)
FROM sys.all_columns
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
PRINT '***'
SELECT COUNT(*)
FROM @T AS a
INNER JOIN @T AS b ON (a.name LIKE '%' + b.name + '%')
PRINT '***'
SELECT COUNT(*)
FROM @T AS a
INNER JOIN @T AS b ON (PATINDEX('%' + b.name + '%', a.name) > 0)
这为两者提供了基本相同的计划,但也包含了以下各种内部函数。
Table '#5DB5E0CB'. Scan count 2, logical reads 40016
CPU time = 26953 ms, elapsed time = 28083 ms.
Table '#5DB5E0CB'. Scan count 2, logical reads 40016
CPU time = 28329 ms, elapsed time = 29458 ms.
但是我注意到,如果我用#temp
表替换表变量,那么进入流聚合的估计行数就会大不相同。
LIKE
版估计有330,596和PATINDEX
估计为1,875,000。
我注意到你的计划中也有一个哈希联接。可能是因为PATINDEX
版本似乎估计的行数大于LIKE
,因此此查询获得更大的内存授权,因此不必将散列操作溢出到光盘。尝试在Profiler中跟踪哈希警告以查看是否是这种情况。
答案 2 :(得分:1)