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

確實如此，但沒有回答所問的問題是關於兩個特定查詢的性能。 –

回答