I would expect these two SELECT
s to have the same execution plan and performance. Since there is a leading wildcard on the LIKE
, I expect an index scan
These tests (database AdventureWorks2008R2) shows what happens:
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;
Results:
Test #1
Table 'Person'. Scan count 1, logical reads 106
Test #2
Table 'Person'. Scan count 1, logical reads 106
The results from SET STATISTICS IO
shows that LIO are the same.
But the execution plans are quite different:
In the first test, SQL Server uses an Index Scan
explicit but in the second test SQL Server uses an Index Seek
which is an Index Seek - range scan
. In the last case SQL Server uses a Compute Scalar
operator to generate these values
[Expr1005] = Scalar Operator(LikeRangeStart([@Pattern])),
[Expr1006] = Scalar Operator(LikeRangeEnd([@Pattern])),
[Expr1007] = Scalar Operator(LikeRangeInfo([@Pattern]))
and, the Index Seek
operator use an Seek Predicate
(optimized) for a range scan
(LastName > LikeRangeStart AND LastName < LikeRangeEnd
) plus another unoptimized Predicate
(LastName LIKE @pattern
).
How can LIKE '%...' seek on an index?
My answer: it isn't a "real" Index Seek
. It's a Index Seek - range scan
which, in this case, has the same performance like Index Scan
.
Please see, also, the difference between Index Seek
and Index Scan
(similar debate):
So…is it a Seek or a Scan?.
Edit 1: The execution plan for OPTION(RECOMPILE)
(see Aaron's recommendation please) shows, also, an Index Scan
(instead of Index Seek
):