TSQL wildcard performance: results of variable or specific length query - performance

Question

In a table, I have an index on column ID (VARCHAR).
Given that an index exists, I would expect
Select Top 1 * from table where ID like 'abc%' order by ID desc
to be very fast.
I then did a
set statistics io on
to compare and found that
Select Top 1 * from table where ID like 'abc___' order by ID desc
is also very fast (same number of reads, 5 in my case). The actual execution plan also shows excactly the same, index seek and key lookup in both cases.
From my understanding, it should not be able to use the index and hence have significantly more reads.
With the index being ordered, with the 'abc%' it should just be able to jump to the end of the index where there is a match starting with abc. But with me asking for a specific length with 'abc___' it should not be able to directly jump to some place in the index but should have to scan all entries starting with 'abc' for their length.
There are several 1000 entries in that format in the table.
Why is querying for 'abc___' as fast as querying for 'abc%'?

Answer 1

To replicate this, I set up a simple reproduction of your environment:
IF OBJECT_ID(N'tempdb..#T', 'U') IS NOT NULL DROP TABLE #T;
CREATE TABLE #T (ID VARCHAR(8) NOT NULL PRIMARY KEY);
INSERT #T (ID)
SELECT TOP 100000 123000 + CONVERT(VARCHAR(6), ROW_NUMBER() OVER(ORDER BY a.object_id))
FROM sys.all_objects a, sys.all_objects b
UNION ALL
SELECT TOP 100000 12300000 + CONVERT(VARCHAR(6), ROW_NUMBER() OVER(ORDER BY a.object_id))
FROM sys.all_objects a, sys.all_objects b;
SELECT COUNT(*)
FROM #T
WHERE ID LIKE '123%';
SELECT COUNT(*)
FROM #T
WHERE ID LIKE '123___';
When viewing the exection plan, as you hvae said, both use the same index seek:
and if you inspect the plan further, you can see both start off with the same range seek:
<SeekPredicateNew>
<SeekKeys>
<StartRange ScanType="GE">
<RangeColumns>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[#T]" Column="ID" />
</RangeColumns>
<RangeExpressions>
<ScalarOperator ScalarString="'123'">
<Const ConstValue="'123'" />
</ScalarOperator>
</RangeExpressions>
</StartRange>
<EndRange ScanType="LT">
<RangeColumns>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[#T]" Column="ID" />
</RangeColumns>
<RangeExpressions>
<ScalarOperator ScalarString="'124'">
<Const ConstValue="'124'" />
</ScalarOperator>
</RangeExpressions>
</EndRange>
</SeekKeys>
</SeekPredicateNew>
The only difference behind the scenes of both seeks is the second, where one further filters by LIKE '123%' and the other LIKE '123___'.
I think your misunderstanding may be that the index seek has to correctly identify the records in one go. This is not the case, in the case of the second query, the index seek will find the correct range, and then a further filter will identify the relevant rows from this range.

Answer 2

Why do you think 'abc%' it should just be able to jump to the end of the index.
The index is indeed ordered but the engine still has to inspect the individual values to find the first value that does not match 'abc%'. It does not know what that value is until it finds it. The next value could be 'abd', 'abf', 'ax'.