1、SQLServe沖全文搜索與Like的差異分析在SQLServe中, Like關鍵字可以實現模糊查詢，即確定特定字符串是否與 制定模式相匹配。這里的模式可以指包含常規字符和通配符。 在模式匹配過程中， 常規字符必須與字符串中指定的字符完全匹配。不過通過使用通配符可以改變這 個規則，如使用？等通配符可以與字符串的任意部分相匹配。故Like關鍵字可以在數據庫中實現模糊查詢。另外數據庫庫管理員也可以利用全文搜索功能對SQLServer數據表進行查詢。在可以對給定的標進行全文查詢之前， 數據庫管理元必須對這個數據表建立全文 索引。全文索引也可以實現類似Like的模糊查詢功能。如在一張人才簡歷表中查 找

2、符合特定字符串的信息等等。雖然說Like關鍵字與全文搜索在功能上大同小異， 但是在實現細節上有比較大的差異。作為數據庫管理員需要了解這個差異，并選 擇合適的實現模式。一、查詢效率上的差異。通常情況下，Like關鍵字的查詢效率還是比較快的。特別是對于結構化的數 據，Like的查詢效率、靈活性方面是值得稱道的。但是對于一些非機構化的文本 數據，如果通過Like關鍵字來進行模糊查詢的話，則其執行效率并不是很理想。 特別是對于全文查詢來說，其速度要慢得多。而且隨著記錄數量的增多，類似的 差異更明顯。如在一張表中，有三百萬行左右的文本數據，此時如果利用Like關鍵字來查找相關的內容，則可能需要幾分鐘的時

3、間才能夠返回正確的結果。 相反,對于同樣的數據通過采用全文搜索功能的話， 則可能只需要1分鐘不到甚至更多 的時間及可以返回結果。故當文本數據的行數比較多時，如在一萬行以上，則此 時數據庫管理員若采用全文搜索功能的話，則可以比較明顯的改善數據庫的查詢效率。二、對空格字符的敏感性。在數據庫中如果采用Like關鍵字進行模糊查詢，則在這個關鍵字后面的所有 字符都有意義。如現在用戶使用like “abed”有兩個空格）查詢時，則后面的空格 字符對于Like關鍵字也是敏感的。也就是說，如果用戶利用上面這條語句進行查 詢時，則被查詢的內容必須也是“abed帶有兩個空格）這種類型的數據才會被返回。如果被查詢的

4、內容是“abed不帶空格或者帶有一個空格）則數據庫系統會認 為這與查詢條件不相符合，故不會返回相關的記錄。故Like關鍵字對于空格是比 較敏感的。為此在使用Like關鍵字時候需要特別注意這個問題。 如果用戶或者程 序開發人員不能夠確定abed后面到底是否有空格，則可以通過通配符拉實現。 即可以利用” abcd%為條件語句。如此的話，無論 abed前面或者后面是否有空 格，則都會被查詢出來。但是全文搜索的話，通常情況下系統會把空格忽略掉。 即在全文搜索功能中，系統會先對查詢條件語句進行優化。如果發現空格的話， 則往往會實現把空格過濾掉。故全文搜索的話，對于空格等特殊字符往往是不敏 感的。三、對于

5、一些特殊字符的處理要求。由于數據類型不同，其數據存儲方式也不同。為此某些特殊的數據類型可能 無法通過Like關鍵字來實現模糊查詢。如對于辦好ehar和varchar數據的模式的字符串比較可能無法通過Like關鍵字來實現。也就是說，Like關鍵字后面帶的條 件語句僅對字符模式有效，不能夠使用Like條件語句來查詢格式化的二進制數據 等等。為此如果數據庫管理元要采用 Like關鍵字，則其必須了解每種數據類型的 存儲方式以及導致Like關鍵字比較失敗的原因。知己知彼，百戰百勝。只有如此 數據庫管理員才能夠避免因為在不恰當的地方采用了Like關鍵字而造成查詢的錯誤。不過值得高興的是，Like關鍵字支持

6、ASCI模式匹配與Unicode模式匹配。 如果Like關鍵字的所有參數都為ASCII字符數據類型，則Like關鍵字會自動采用 ASCII模式匹配。如果其中任何一個參數為 Uni code數據類型，則系統會把所有的 參數都轉換為Unicode數據類型，并執行Unicode模式匹配。另外需要注意的是， 如果Like關鍵字加上Unicode的數據類型則后面條件語句的空格是有效的，即比較時會考慮到后面出現的空格。但是如果數據類型不是Unicode的，則對后面的空格不敏感。即比較時，是否存在空格對于最后的結果不會有影響。但是如果數據庫管理員才用全文搜索的話，往往沒有這方面的顧慮。因為全 文搜索不僅支持

7、傳統的字符模式，而且還支持其他的數據模式。另外通過全文搜 索，還可以用來查詢格式化的二進制數據。為此如果在數據表中，數據模式不統 一或者需要對二進制數據進行查詢的話，則必這建議數據庫管理員需要采用全文搜索，而不是采用Like關鍵字。四、轉義字符對查詢的影響。如現在在數據表中有百分制的數值。如某個序號為 10的產品的不合格率為 10%。此時用戶可能需要找出這個合格率為 10%的內容，并進行后續的操作。但 是10%其中的是一個比較特殊的字符，它是數據庫中的通配符。如果利用Like ” 10進行查詢的話，則數據庫會把10與10%的內容都查找出來。顯然這不 符合我們的需要。為了避免這種通配符等特殊字符

8、給Like查詢帶來的不利影響，則需要通過Escape子句來搜索包含一個或者多個特殊通配符的字符串。如上面的 例子中，要把當作普通字符而不是通配符，就必須提供 Escape關鍵字和轉義符 號。如果Like模式中的轉義符后面沒有字符，則該模式無效并且LIKE返回False. 如果轉義符后面的字符不是通配符，則將放棄轉義符并將該轉義符后面的字符作 為該模式中的常規字符處理。不過在全文搜索中就不會受到這個轉義字符的影響。如現在在數據庫中有abed、ab、abef、ab*等行。現在數據庫管理員希望能 夠查找出以ab字符開頭的行，即實現前綴搜索。此時數據庫管理員就可以通 過“top這'個條件語句來

9、完成。此時系統就會返回所有與星號之前制定的文本相 匹配的文本。如果此時數據庫管理員只想查找 ab*的記錄，則就可以使用'top*不（ 包含雙引號）條件語句來完成查詢需求。即如果未在文本和星號前后加上雙引號的 話，則全文搜索將不把星號當作通配符。這就比使用轉義字符要簡單的多。五、具體應用的差異。由于全文搜索與Like關鍵字在功能與性能上的一些差異，故他們在應用領域 上也有所差別。SQLServe數據庫在設計的時候，也是讓他們各自負責一塊領域。 如相比Like掛泥漿案子而言，全文瑣碎可能根據下面這些內容來實現特定的查詢。 如可以根據一個或則多個特定的詞和短語來進行查詢；可以通過特定詞的變形

10、來 進行查詢;如可以與另一個詞或短語鄰近的詞或者短語；如可以對特定詞的同義詞 形式來進行查詢；如可以通過加權值的詞或者短語來實現查詢等等。正是因為全文搜索這些特異功能，決定了全文搜索在一些特定的場合中特別有用。據考試大了解，全文搜索在如下幾個應用領域有比較突出的表現。一是在電 子商務網站上，用戶可以通過全文搜索功能在網站主頁上根據產品規格或者名字 來實現模糊查詢。二是在一些人才網站上，可以通過學歷、工作經驗、技術特長 等條件在后臺數據庫中查找需要的人才信息等等。 不管是什么樣的商業應用場景， 全文搜索的基本管理任務和開發任務是相同的。 不過，在給定的商業應用場景中， 可以對全文索引和查詢進行優化以使其滿足業務目標。例如，對于電子商務來說，限度地提高性能可能比對結果進行排序、檢索的準確性（實際上有多少個現有匹配 項是由全文查詢返回的）或支持多種語言更重要。對于律師事務所來說，首先需要 考慮的可能是返回所有可能存在的匹配項。到目前為止，筆者參與