带有参数化 LIKE 的意外表扫描

Question

参数化LIKE语句时，我在 SQL Server 2005 上遇到了针对堆表的意外表扫描......但是当与变量相同的值被硬编码时，会发生预期的索引查找。

这个问题只发生在这种特定的情况下......所以我对如何解决这个问题并不感到困惑，我对为什么会发生这种情况感到困惑。

以下 T-SQL 应在 SQL Server 2005 上重现该问题：

IF (OBJECT_ID('tempdb.dbo.#tblTest') IS NOT NULL)
    DROP TABLE dbo.#tblTest
GO

CREATE TABLE dbo.#tblTest (
    ID INT IDENTITY(1, 1),
    SerialNumber VARCHAR(50)
)
GO

-- Populate the table with 10,000 rows
SET NOCOUNT ON
DECLARE @i INT
SET @i = 0

WHILE @i < 10000
BEGIN
    INSERT INTO dbo.#tblTest VALUES(CAST(@i AS VARCHAR(10)))
    SET @i = @i + 1
END
GO

-- To recreate the issue, the table must be a heap.
ALTER TABLE dbo.#tblTest ADD CONSTRAINT PK_tblTest PRIMARY KEY NONCLUSTERED (ID)
GO

-- Create a (non-covering) index on serial number.
CREATE NONCLUSTERED INDEX IX_tblTest_SerialNumber ON dbo.#tblTest (SerialNumber)
GO

DECLARE @Criteria VARCHAR(50)
SET @Criteria = '1234%'

-- This produces a Table Scan.
SELECT * 
FROM dbo.#tblTest
WHERE SerialNumber LIKE @Criteria

-- This produces an Index Seek
SELECT *
FROM dbo.#tblTest
WHERE SerialNumber LIKE '1234%'

我被保罗·怀特 (Paul White) 指向这篇文章，它似乎非常相关，但结论/解释与我的具体问题不符。

任何见解表示赞赏。

Answer 1

它发生的要求仅用于非聚集索引是由于这样的事实，你只有两列-一个是索引列，另一个是

1. 如果有聚集索引，则为聚集键（即另一列）
2. 如果没有聚集索引，则为 RID

在第二种情况下，为了满足查询的SELECT *（所有列）部分，它必须执行昂贵的查找，因此选择执行 10,000* 记录表扫描的通用（稳健）计划。在第一种情况下，索引是满足 SELECT 子句所需的全部内容。

*应该注意的是，记录数和索引基数也在确定计划中起作用。

根据下面的修订测试，即使使用聚集索引，对于更多列，计划也可以预测地切换到参数化 LIKE 语句的 CLUSTERED INDEX SCAN。

IF (OBJECT_ID('tempdb.dbo.#tblTest') IS NOT NULL)
    DROP TABLE dbo.#tblTest
GO

CREATE TABLE dbo.#tblTest (
    ID INT IDENTITY(1, 1),
    SerialNumber VARCHAR(50),
    Othercolumn1 uniqueidentifier default (newid()),
    RowVer timestamp
)
GO

-- Populate the table with 10,000 rows
SET NOCOUNT ON
DECLARE @i INT
SET @i = 0

WHILE @i < 10000
BEGIN
    INSERT INTO dbo.#tblTest (serialnumber) VALUES(CAST(@i AS VARCHAR(10)))
    SET @i = @i + 1
END
GO

-- To recreate the issue, the table must be a heap.
ALTER TABLE dbo.#tblTest ADD CONSTRAINT PK_tblTest PRIMARY KEY CLUSTERED (ID)
GO

-- Create a (non-covering) index on serial number.
CREATE NONCLUSTERED INDEX IX_tblTest_SerialNumber ON dbo.#tblTest (SerialNumber)
GO

DECLARE @Criteria VARCHAR(50)
SET @Criteria = '1234%'

-- This produces a Table Scan.
SELECT * 
FROM dbo.#tblTest
WHERE SerialNumber LIKE @Criteria

-- This produces an Index Seek
SELECT *
FROM dbo.#tblTest
WHERE SerialNumber LIKE '1234%'

以下是根据我修改后的表格结构生成的计划。对于问题中的模式，顶部成为表扫描，底部成为 RID 查找而不是键查找 - 其他一切都相同。

执行查询时开销较大的操作之一是首先构建执行计划。为了帮助实现这一点，SQL Server 有一个计划缓存，用于存储语句文本和相关的 SET 设置。相同的文本使用不同的 SET 设置可能会导致不同的行为，因此重新规划并存储为单独的条目。

非参数化查询很容易规划 - 它包含确切的文本“1234%”。可以轻松搜索 SerialNumber 上的 VARCHAR 索引以查找包含前缀“1234”的部分。SQL Server 还会估计查询的基数，并且总是为您的数据选择 INDEX SEEK 计划。向 SQL Server 进一步展示确切的查询语句（文本）将包含静态值“1234%”，并且可以安全地有效地重新执行相同的计划。

另一方面，参数化查询存储到由语句 text 键控的计划缓存（字典）中... WHERE SerialNumber LIKE @Criteria。即使当前批处理中的@Criteria 包含值“1234%”并且可以使用 INDEX SEEK，其他用户也很可能提交完全相同的查询，@Criteria并将设置为“%9”，而使用INDEX SEEK + RID 查找。这将 SELECT 10% 的数据，这些数据通常超过索引查找不再有利的临界点。为了健壮性和可重用性，为此查询缓存（然后执行）的计划是表扫描版本，它将以@Criteria平均效率在可能的值中满足最广泛的值范围。