9

我希望这两个SELECT具有相同的执行计划和性能。由于 上有一个前导通配符LIKE,我希望进行索引扫描。当我运行它并查看计划时,第一个SELECT行为符合预期(通过扫描)。但是第二个SELECT计划显示了索引搜索,并且运行速度快了 20 倍。

代码:

-- Uses index scan, as expected:
SELECT 1
    FROM AccountAction
    WHERE AccountNumber LIKE '%441025586401'

-- Uses index seek somehow, and runs much faster:
declare @empty VARCHAR(30) = ''
SELECT 1
    FROM AccountAction
    WHERE AccountNumber LIKE '%441025586401' + @empty

问题:

当模式以通配符开头时,SQL Server 如何使用索引查找?

奖金问题:

为什么连接一个空字符串会改变/改进执行计划?

细节:

  • 有一个非聚集索引Accounts.AccountNumber
  • 还有其他索引,但查找和扫描都在索引上。
  • Accounts.AccountNumber列可以为空varchar(30)
  • 服务器是 SQL Server 2012

表和索引定义:

CREATE TABLE [updatable].[AccountAction](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [AccountNumber] [varchar](30) NULL,
    [Utility] [varchar](9) NOT NULL,
    [SomeData1] [varchar](10) NOT NULL,
    [SomeData2] [varchar](200) NULL,
    [SomeData3] [money] NULL,
    --...
    [Created] [datetime] NULL,
 CONSTRAINT [PK_Account] PRIMARY KEY NONCLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]


CREATE NONCLUSTERED INDEX [IX_updatable_AccountAction_AccountNumber_UtilityCode_ActionTypeCd] ON [updatable].[AccountAction]
(
    [AccountNumber] ASC,
    [Utility] ASC
)
INCLUDE ([SomeData1], [SomeData2], [SomeData3]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]


CREATE CLUSTERED INDEX [CIX_Account] ON [updatable].[AccountAction]
(
    [Created] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

注意:这是两个查询的实际执行计划。对象的名称与上面的代码略有不同,因为我试图让问题保持简单。

两个执行计划。

4

1 回答 1

8

这些测试(数据库 AdventureWorks2008R2)显示了会发生什么:

SET NOCOUNT ON;
SET STATISTICS IO ON;

PRINT 'Test #1';
SELECT  p.BusinessEntityID, p.LastName
FROM    Person.Person p
WHERE   p.LastName LIKE '%be%';

PRINT 'Test #2';
DECLARE @Pattern NVARCHAR(50);
SET @Pattern=N'%be%';
SELECT  p.BusinessEntityID, p.LastName
FROM    Person.Person p
WHERE   p.LastName LIKE @Pattern;

SET STATISTICS IO OFF;
SET NOCOUNT OFF;

结果:

Test #1
Table 'Person'. Scan count 1, logical reads 106
Test #2
Table 'Person'. Scan count 1, logical reads 106

结果SET STATISTICS IO表明 LIO 是相同的。但是执行计划完全不同: 在此处输入图像描述

在第一个测试中,SQL Server 使用Index Scan显式,但在第二个测试中,SQL Server 使用 an Index Seekwhich is an Index Seek - range scan. 在最后一种情况下,SQL Server 使用Compute Scalar运算符来生成这些值

[Expr1005] = Scalar Operator(LikeRangeStart([@Pattern])), 
[Expr1006] = Scalar Operator(LikeRangeEnd([@Pattern])), 
[Expr1007] = Scalar Operator(LikeRangeInfo([@Pattern]))

并且,Index Seek运算符对 ( ) 使用(Seek Predicate优化的)加上另一个未优化的( )。range scanLastName > LikeRangeStart AND LastName < LikeRangeEndPredicateLastName LIKE @pattern

LIKE '%...' 如何在索引上查找?

我的回答:它不是“真实的” Index Seek。在这种情况下,它Index Seek - range scan具有与Index Scan.

另请参阅Index SeekIndex Scan(类似辩论)之间的区别: 那么……它是搜索还是扫描?.

编辑 1:(请参阅 Aaron 的建议)的执行计划OPTION(RECOMPILE)还显示Index Scan(而不是Index Seek): 在此处输入图像描述

于 2013-08-05T20:07:47.173 回答