SQLServer中全文搜索與Like的差異分析
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
在SQL Server中,Like關鍵字可以實現模糊查詢,即確定特定字符串是否與制定模式相匹配。這里的模式可以指包含常規字符和通配符。在模式匹配過程中,常規字符必須與字符串中指定的字符完全匹配。不過通過使用通配符可以改變這個規則,如使用?等通配符可以與字符串的任意部分相匹配。故Like關鍵字可以在數據庫中實現模糊查詢。 另外數據庫庫管理員也可以利用全文搜索功能對SQL Server數據表進行查詢。在可以對給定的標進行全文查詢之前,數據庫管理元必須對這個數據表建立全文索引。全文索引也可以實現類似Like的模糊查詢功能。如在一張人才簡歷表中查找符合特定字符串的信息等等。雖然說Like關鍵字與全文搜索在功能上大同小異,但是在實現細節上有比較大的差異。作為數據庫管理員需要了解這個差異,并選擇合適的實現模式。 一、 查詢效率上的差異。 通常情況下,Like關鍵字的查詢效率還是比較快的。特別是對于結構化的數據,Like的查詢效率、靈活性方面是值得稱道的。但是對于一些非機構化的文本數據,如果通過Like關鍵字來進行模糊查詢的話,則其執行效率并不是很理想。特別是對于全文查詢來說,其速度要慢得多。而且隨著記錄數量的增多,類似的差異更明顯。如在一張表中,有三百萬行左右的文本數據,此時如果利用Like關鍵字來查找相關的內容,則可能需要幾分鐘的時間才能夠返回正確的結果。相反,對于同樣的數據通過采用全文搜索功能的話,則可能只需要1分鐘不到甚至更多的時間及可以返回結果。故當文本數據的行數比較多時,如在一萬行以上,則此時數據庫管理員若采用全文搜索功能的話,則可以比較明顯的改善數據庫的查詢效率。 二、 對空格字符的敏感性。 在數據庫中如果采用Like關鍵字進行模糊查詢,則在這個關鍵字后面的所有字符都有意義。如現在用戶使用like “abcd ”(帶有兩個空格)查詢時,則后面的空格字符對于Like關鍵字也是敏感的。也就是說,如果用戶利用上面這條語句進行查詢時,則被查詢的內容必須也是“abcd ”(帶有兩個空格)這種類型的數據才會被返回。如果被查詢的內容是“abcd ”(不帶空格或者帶有一個空格)則數據庫系統會認為這與查詢條件不相符合,故不會返回相關的記錄。故Like關鍵字對于空格是比較敏感的。為此在使用Like關鍵字時候需要特別注意這個問題。如果用戶或者程序開發人員不能夠確定abcd后面到底是否有空格,則可以通過通配符拉實現。即可以利用”%abcd%”為條件語句。如此的話,無論abcd前面或者后面是否有空格,則都會被查詢出來。但是全文搜索的話,通常情況下系統會把空格忽略掉。即在全文搜索功能中,系統會先對查詢條件語句進行優化。如果發現空格的話,則往往會實現把空格過濾掉。故全文搜索的話,對于空格等特殊字符往往是不敏感的。 三、 對于一些特殊字符的處理要求。 由于數據類型不同,其數據存儲方式也不同。為此某些特殊的數據類型可能無法通過Like關鍵字來實現模糊查詢。如對于辦好char和varchar數據的模式的字符串比較可能無法通過Like關鍵字來實現。也就是說,Like關鍵字后面帶的條件語句僅對字符模式有效,不能夠使用Like條件語句來查詢格式化的二進制數據等等。為此如果數據庫管理元要采用Like關鍵字,則其必須了解每種數據類型的存儲方式以及導致Like關鍵字比較失敗的原因。知己知彼,百戰百勝。只有如此數據庫管理員才能夠避免因為在不恰當的地方采用了Like關鍵字而造成查詢的錯誤。不過值得高興的是,Like關鍵字支持ASCII模式匹配與Unicode模式匹配。如果Like關鍵字的所有參數都為ASCII字符數據類型,則Like關鍵字會自動采用ASCII模式匹配。如果其中任何一個參數為Unicode數據類型,則系統會把所有的參數都轉換為Unicode數據類型,并執行Unicode模式匹配。另外需要注意的是,如果Like關鍵字加上Unicode的數據類型則后面條件語句的空格是有效的,即比較時會考慮到后面出現的空格。但是如果數據類型不是Unicode的,則對后面的空格不敏感。即比較時,是否存在空格對于最后的結果不會有影響。 但是如果數據庫管理員才用全文搜索的話,往往沒有這方面的顧慮。因為全文搜索不僅支持傳統的字符模式,而且還支持其他的數據模式。另外通過全文搜索,還可以用來查詢格式化的二進制數據。為此如果在數據表中,數據模式不統一或者需要對二進制數據進行查詢的話,則必這建議數據庫管理員需要采用全文搜索,而不是采用Like關鍵字。 四、 轉義字符對查詢的影響。 如現在在數據表中有百分制的數值。如某個序號為10的產品的不合格率為10%。此時用戶可能需要找出這個合格率為10%的內容,并進行后續的操作。但是10%其中的%是一個比較特殊的字符,它是數據庫中的通配符。如果利用Like ”10%”進行查詢的話,則數據庫會把10與10%的內容都查找出來。顯然這不符合我們的需要。為了避免這種通配符等特殊字符給Like查詢帶來的不利影響,則需要通過Escape子句來搜索包含一個或者多個特殊通配符的字符串。如上面的例子中,要把%當作普通字符而不是通配符,就必須提供Escape關鍵字和轉義符號。如果Like模式中的轉義符后面沒有字符,則該模式無效并且 LIKE 返回False。如果轉義符后面的字符不是通配符,則將放棄轉義符并將該轉義符后面的字符作為該模式中的常規字符處理。不過在全文搜索中就不會受到這個轉義字符的影響。 如現在在數據庫中有abcd、ab、abef、ab*等行。現在數據庫管理員希望能夠查找出以ab字符開頭的行,即實現前綴搜索。此時數據庫管理員就可以通過’ “top*”’這個條件語句來完成。此時系統就會返回所有與星號之前制定的文本相匹配的文本。如果此時數據庫管理員只想查找ab*的記錄,則就可以使用’ top*’(不包含雙引號)條件語句來完成查詢需求。即如果未在文本和星號前后加上雙引號的話,則全文搜索將不把星號當作通配符。這就比使用轉義字符要簡單的多。
五、 具體應用的差異。 由于全文搜索與Like關鍵字在功能與性能上的一些差異,故他們在應用領域上也有所差別。SQL Server數據庫在設計的時候,也是讓他們各自負責一塊領域。如相比Like掛泥漿案子而言,全文瑣碎可能根據下面這些內容來實現特定的查詢。如可以根據一個或則多個特定的詞和短語來進行查詢;可以通過特定詞的變形來進行查詢;如可以與另一個詞或短語鄰近的詞或者短語;如可以對特定詞的同義詞形式來進行查詢;如可以通過加權值的詞或者短語來實現查詢等等。正是因為全文搜索這些特異功能,決定了全文搜索在一些特定的場合中特別有用。 據考試大了解,全文搜索在如下幾個應用領域有比較突出的表現。一是在電子商務網站上,用戶可以通過全文搜索功能在網站主頁上根據產品規格或者名字來實現模糊查詢。二是在一些人才網站上,可以通過學歷、工作經驗、技術特長等條件在后臺數據庫中查找需要的人才信息等等。不管是什么樣的商業應用場景,全文搜索的基本管理任務和開發任務是相同的。不過,在給定的商業應用場景中,可以對全文索引和查詢進行優化以使其滿足業務目標。例如,對于電子商務來說,最大限度地提高性能可能比對結果進行排序、檢索的準確性(實際上有多少個現有匹配項是由全文查詢返回的)或支持多種語言更重要。對于律師事務所來說,首先需要考慮的可能是返回所有可能存在的匹配項。到目前為止,筆者參與過電子商務項目、律師案例庫等幾個項目中都采用了全文搜索功能,都取得了比較不錯的效果。 總的來說,在一些簡單查詢中,使用Like關鍵字來實現模糊查詢可能會取得比較好的效果。但是在一些比較復雜的查詢應用中,特別是需要在大文本中查詢相關的內容,則最好通過全文搜索來實現查詢。此時后者無論在性能上、還是在準確度上都會有比較出色的表現。 該文章在 2011/2/24 10:42:19 編輯過 |
關鍵字查詢
相關文章
正在查詢... |