TSQL通配符性能疑问：可变与固定长度查询为何性能一致？

核心原因其实出在你的查询写法上——TOP 1 ... ORDER BY ID DESC这个需求让SQL Server可以走反向索引查找，完全避开了你担心的「扫描数千条前缀匹配行」的操作，所以两者IO次数和执行计划才会一模一样。

我给你拆解一下：

• 先看LIKE 'abc%'的情况：因为你的ID列建了有序索引，SQL Server可以直接跳转到所有以abc开头的索引条目中的最后一条（也就是字典序最大的那个ID），直接取这条数据就满足TOP 1 DESC的需求，所以只需要几次IO就搞定。

• 再看LIKE 'abc___'的情况：你以为它得扫描所有abc开头的行来判断长度，但SQL Server的查询优化器可机灵了——它能把abc___解析成「以abc开头，且总长度恰好为6的字符串」。结合你要找最大符合条件ID的需求，它会在索引里反向查找：从索引的末尾往前找，直到找到第一个满足「以abc开头且长度为6」的条目。

  因为索引是按ID有序存储的，所有abc开头的条目都集中在一个连续区间里，而其中长度为6的最大ID就是这个区间里最后一个长度为6的条目。SQL Server可以通过索引的有序性快速定位到这个位置，根本不需要扫描那数千条abc开头的行，所以IO次数和前者完全一致。

• 给你个反例验证：如果去掉TOP 1和ORDER BY，直接执行SELECT * FROM table WHERE ID LIKE 'abc___'，这时候SQL Server就不得不扫描所有abc开头的行来过滤长度，IO次数会瞬间飙升到你预期的水平。

内容的提问来源于stack exchange，提问作者Andreas Reiff