LIKE查询，结果集越来越慢

假设我有一个200000记录的Person表，它的GUID主键上有一个聚集索引。此GUID使用SQL Server（2008 R2）提供的NEWSEQUENTIALID（）构造生成。此外，LastName（varchar（256））列上还有一个常规索引。LIKE查询，结果集越来越慢

对于我生成的唯一名称（Lastname_1到Lastname_200000）的每个记录，现在我正在玩弄一些查询，并且发现我的标准越严格，较慢的SQL Server将返回实际结果。而这种表现意义相当严重。

如：

SELECT * FROM Person WHERE Lastname LIKE '%Lastname_123456%'

比慢得多

SELECT * FROM Person WHERE Lastname LIKE '%Lastname_123%'

Responsetimes是通过在设置统计测量：我能想象这所引起

SET STATISTICS TIME ON

）因为LIKE条款本身，因为它与％开始，不可能用不知疲倦的在那个特定的列，

2），具有多想想我的“大问题”的SQL。

这有什么道理吗？有没有办法避免这种情况？

编辑：在一定范围内添加到这个问题，这是一个用例的“免费搜索”的一部分。当用户输入完整姓氏时，我非常希望系统能够快速运行。

我应该如何使这些情况下执行？我应该避免'％xxx％'建设，并且像建设一样去'xxx％'吗？这确实增加速度的很多，但在一些灵活性，为用户的成本...

2012-06-25 fuaaark

请显示执行计划。也许不同的选择性估计值意味着一个聚簇索引扫描，另一个是NCI扫描和密钥查找。 –

你是否顺序产生了所有名字？ –

和许多DB一样，是的。前缀或后缀类似可以使用索引，但不是那种类型的索引，因为数据库只是不知道范围，并且不能将其应用于索引。此外，这是一个相当长的字符串，所以它也会给你带来压力 – Sammaye

你是对的上号2，由于第二LIKE必须在字符串中的多个字符匹配，SQL停止时，发现搜索一个字符不匹配，所以它会花费较少的字符串匹配迭代来查找较小的搜索字符串 - 即使您获得更多结果。

至于＃1 - 如果可能的SQL使用索引的喜欢，但因为寻求可能会做一个索引扫描（可能是聚集索引）是不可能的通配符。这也取决于什么是包含在索引中 - 因为你是选择所有列，很可能是一个表扫描，而不是发生以来，该指数你“可能”的使用不涉及您的查询（除非使用聚集索引）

检查执行计划 - 你可能会看到一个表扫描

2012-06-25 10:43:40 Charleh

通常情况下，SQL Server不上LIKE使用索引。

This文章可以帮助你引导

2012-06-25 11:17:25 Diego

确实如此，但没有回答所问的问题是关于两个特定查询的性能。 –

回答