在SQL Server中，Like關(guān)鍵字可以實現(xiàn)模糊查詢，即確定特定字符串是否與制定模式相匹配。這里的模式可以指包含常規(guī)字符和通配符。在模式匹配過程中，常規(guī)字符必須與字符串中指定的字符完全匹配。不過通過使用通配符可以改變這個規(guī)則，如使用?等通配符可以與字符串的任意部分相匹配。故Like關(guān)鍵字可以在數(shù)據(jù)庫中實現(xiàn)模糊查詢。
　　另外數(shù)據(jù)庫庫管理員也可以利用全文搜索功能對SQL Server數(shù)據(jù)表進(jìn)行查詢。在可以對給定的標(biāo)進(jìn)行全文查詢之前，數(shù)據(jù)庫管理元必須對這個數(shù)據(jù)表建立全文索引。全文索引也可以實現(xiàn)類似Like的模糊查詢功能。如在一張人才簡歷表中查找符合特定字符串的信息等等。雖然說Like關(guān)鍵字與全文搜索在功能上大同小異，但是在實現(xiàn)細(xì)節(jié)上有比較大的差異。作為數(shù)據(jù)庫管理員需要了解這個差異，并選擇合適的實現(xiàn)模式。
　　一、 查詢效率上的差異。
　　通常情況下，Like關(guān)鍵字的查詢效率還是比較快的。特別是對于結(jié)構(gòu)化的數(shù)據(jù)，Like的查詢效率、靈活性方面是值得稱道的。但是對于一些非機(jī)構(gòu)化的文本數(shù)據(jù)，如果通過Like關(guān)鍵字來進(jìn)行模糊查詢的話，則其執(zhí)行效率并不是很理想。特別是對于全文查詢來說，其速度要慢得多。而且隨著記錄數(shù)量的增多，類似的差異更明顯。如在一張表中，有三百萬行左右的文本數(shù)據(jù)，此時如果利用Like關(guān)鍵字來查找相關(guān)的內(nèi)容，則可能需要幾分鐘的時間才能夠返回正確的結(jié)果。相反，對于同樣的數(shù)據(jù)通過采用全文搜索功能的話，則可能只需要1分鐘不到甚至更多的時間及可以返回結(jié)果。故當(dāng)文本數(shù)據(jù)的行數(shù)比較多時，如在一萬行以上，則此時數(shù)據(jù)庫管理員若采用全文搜索功能的話，則可以比較明顯的改善數(shù)據(jù)庫的查詢效率。
　　二、 對空格字符的敏感性。
　　在數(shù)據(jù)庫中如果采用Like關(guān)鍵字進(jìn)行模糊查詢，則在這個關(guān)鍵字后面的所有字符都有意義。如現(xiàn)在用戶使用like “abcd ”(帶有兩個空格)查詢時，則后面的空格字符對于Like關(guān)鍵字也是敏感的。也就是說，如果用戶利用上面這條語句進(jìn)行查詢時，則被查詢的內(nèi)容必須也是“abcd ”(帶有兩個空格)這種類型的數(shù)據(jù)才會被返回。如果被查詢的內(nèi)容是“abcd ”(不帶空格或者帶有一個空格)則數(shù)據(jù)庫系統(tǒng)會認(rèn)為這與查詢條件不相符合，故不會返回相關(guān)的記錄。故Like關(guān)鍵字對于空格是比較敏感的。為此在使用Like關(guān)鍵字時候需要特別注意這個問題。如果用戶或者程序開發(fā)人員不能夠確定abcd后面到底是否有空格，則可以通過通配符拉實現(xiàn)。即可以利用”%abcd%”為條件語句。如此的話，無論abcd前面或者后面是否有空格，則都會被查詢出來。但是全文搜索的話，通常情況下系統(tǒng)會把空格忽略掉。即在全文搜索功能中，系統(tǒng)會先對查詢條件語句進(jìn)行優(yōu)化。如果發(fā)現(xiàn)空格的話，則往往會實現(xiàn)把空格過濾掉。故全文搜索的話，對于空格等特殊字符往往是不敏感的。

　　三、 對于一些特殊字符的處理要求。
　　由于數(shù)據(jù)類型不同，其數(shù)據(jù)存儲方式也不同。為此某些特殊的數(shù)據(jù)類型可能無法通過Like關(guān)鍵字來實現(xiàn)模糊查詢。如對于辦好char和varchar數(shù)據(jù)的模式的字符串比較可能無法通過Like關(guān)鍵字來實現(xiàn)。也就是說，Like關(guān)鍵字后面帶的條件語句僅對字符模式有效，不能夠使用Like條件語句來查詢格式化的二進(jìn)制數(shù)據(jù)等等。為此如果數(shù)據(jù)庫管理元要采用Like關(guān)鍵字，則其必須了解每種數(shù)據(jù)類型的存儲方式以及導(dǎo)致Like關(guān)鍵字比較失敗的原因。知己知彼，百戰(zhàn)百勝。只有如此數(shù)據(jù)庫管理員才能夠避免因為在不恰當(dāng)?shù)牡胤讲捎昧薒ike關(guān)鍵字而造成查詢的錯誤。不過值得高興的是，Like關(guān)鍵字支持ASCII模式匹配與Unicode模式匹配。如果Like關(guān)鍵字的所有參數(shù)都為ASCII字符數(shù)據(jù)類型，則Like關(guān)鍵字會自動采用ASCII模式匹配。如果其中任何一個參數(shù)為Unicode數(shù)據(jù)類型，則系統(tǒng)會把所有的參數(shù)都轉(zhuǎn)換為Unicode數(shù)據(jù)類型，并執(zhí)行Unicode模式匹配。另外需要注意的是，如果Like關(guān)鍵字加上Unicode的數(shù)據(jù)類型則后面條件語句的空格是有效的，即比較時會考慮到后面出現(xiàn)的空格。但是如果數(shù)據(jù)類型不是Unicode的，則對后面的空格不敏感。即比較時，是否存在空格對于最后的結(jié)果不會有影響。
　　但是如果數(shù)據(jù)庫管理員才用全文搜索的話，往往沒有這方面的顧慮。因為全文搜索不僅支持傳統(tǒng)的字符模式，而且還支持其他的數(shù)據(jù)模式。另外通過全文搜索，還可以用來查詢格式化的二進(jìn)制數(shù)據(jù)。為此如果在數(shù)據(jù)表中，數(shù)據(jù)模式不統(tǒng)一或者需要對二進(jìn)制數(shù)據(jù)進(jìn)行查詢的話，則必這建議數(shù)據(jù)庫管理員需要采用全文搜索，而不是采用Like關(guān)鍵字。
　　四、 轉(zhuǎn)義字符對查詢的影響。
　　如現(xiàn)在在數(shù)據(jù)表中有百分制的數(shù)值。如某個序號為10的產(chǎn)品的不合格率為10%。此時用戶可能需要找出這個合格率為10%的內(nèi)容，并進(jìn)行后續(xù)的操作。但是10%其中的%是一個比較特殊的字符，它是數(shù)據(jù)庫中的通配符。如果利用Like ”10%”進(jìn)行查詢的話，則數(shù)據(jù)庫會把10與10%的內(nèi)容都查找出來。顯然這不符合我們的需要。為了避免這種通配符等特殊字符給Like查詢帶來的不利影響，則需要通過Escape子句來搜索包含一個或者多個特殊通配符的字符串。如上面的例子中，要把%當(dāng)作普通字符而不是通配符，就必須提供Escape關(guān)鍵字和轉(zhuǎn)義符號。如果Like模式中的轉(zhuǎn)義符后面沒有字符，則該模式無效并且 LIKE 返回False。如果轉(zhuǎn)義符后面的字符不是通配符，則將放棄轉(zhuǎn)義符并將該轉(zhuǎn)義符后面的字符作為該模式中的常規(guī)字符處理。不過在全文搜索中就不會受到這個轉(zhuǎn)義字符的影響。

　　如現(xiàn)在在數(shù)據(jù)庫中有abcd、ab、abef、ab*等行?，F(xiàn)在數(shù)據(jù)庫管理員希望能夠查找出以ab字符開頭的行，即實現(xiàn)前綴搜索。此時數(shù)據(jù)庫管理員就可以通過’ “top*”’這個條件語句來完成。此時系統(tǒng)就會返回所有與星號之前制定的文本相匹配的文本。如果此時數(shù)據(jù)庫管理員只想查找ab*的記錄，則就可以使用’ top*’(不包含雙引號)條件語句來完成查詢需求。即如果未在文本和星號前后加上雙引號的話，則全文搜索將不把星號當(dāng)作通配符。這就比使用轉(zhuǎn)義字符要簡單的多。
　　五、 具體應(yīng)用的差異。
　　由于全文搜索與Like關(guān)鍵字在功能與性能上的一些差異，故他們在應(yīng)用領(lǐng)域上也有所差別。SQL Server數(shù)據(jù)庫在設(shè)計的時候，也是讓他們各自負(fù)責(zé)一塊領(lǐng)域。如相比Like掛泥漿案子而言，全文瑣碎可能根據(jù)下面這些內(nèi)容來實現(xiàn)特定的查詢。如可以根據(jù)一個或則多個特定的詞和短語來進(jìn)行查詢;可以通過特定詞的變形來進(jìn)行查詢;如可以與另一個詞或短語鄰近的詞或者短語;如可以對特定詞的同義詞形式來進(jìn)行查詢;如可以通過加權(quán)值的詞或者短語來實現(xiàn)查詢等等。正是因為全文搜索這些特異功能，決定了全文搜索在一些特定的場合中特別有用。
　　據(jù)考試大了解，全文搜索在如下幾個應(yīng)用領(lǐng)域有比較突出的表現(xiàn)。一是在電子商務(wù)網(wǎng)站上，用戶可以通過全文搜索功能在網(wǎng)站主頁上根據(jù)產(chǎn)品規(guī)格或者名字來實現(xiàn)模糊查詢。二是在一些人才網(wǎng)站上，可以通過學(xué)歷、工作經(jīng)驗、技術(shù)特長等條件在后臺數(shù)據(jù)庫中查找需要的人才信息等等。不管是什么樣的商業(yè)應(yīng)用場景，全文搜索的基本管理任務(wù)和開發(fā)任務(wù)是相同的。不過，在給定的商業(yè)應(yīng)用場景中，可以對全文索引和查詢進(jìn)行優(yōu)化以使其滿足業(yè)務(wù)目標(biāo)。例如，對于電子商務(wù)來說，最大限度地提高性能可能比對結(jié)果進(jìn)行排序、檢索的準(zhǔn)確性(實際上有多少個現(xiàn)有匹配項是由全文查詢返回的)或支持多種語言更重要。對于律師事務(wù)所來說，首先需要考慮的可能是返回所有可能存在的匹配項。到目前為止，筆者參與過電子商務(wù)項目、律師案例庫等幾個項目中都采用了全文搜索功能，都取得了比較不錯的效果。
　　總的來說，在一些簡單查詢中，使用Like關(guān)鍵字來實現(xiàn)模糊查詢可能會取得比較好的效果。但是在一些比較復(fù)雜的查詢應(yīng)用中，特別是需要在大文本中查詢相關(guān)的內(nèi)容，則最好通過全文搜索來實現(xiàn)查詢。此時后者無論在性能上、還是在準(zhǔn)確度上都會有比較出色的表現(xiàn)。

該文章在 2011/2/24 10:42:19 編輯過