【正文】 請(qǐng)參閱 SQL Server Books Online。全文查詢查詢?nèi)乃饕c執(zhí)行 SQL Server 中的標(biāo)準(zhǔn)關(guān)系型查詢略有不同。由于索引是在 SQL Server 外部進(jìn)行存儲(chǔ)和管理的，因此全文查詢處理大部分由 MSSearch 完成（因此，那些一部分是關(guān)系型、一部分基于全文的查詢將被單獨(dú)處理），這樣做有時(shí)會(huì)損害性能。從本質(zhì)上說(shuō)，執(zhí)行全文查詢時(shí)，查詢?cè)~傳遞給 MSSearch，后者遍歷其內(nèi)部數(shù)據(jù)結(jié)構(gòu)（索引），并向 SQL Server 返回主鍵和排位值。如果執(zhí)行 CONTAINS 或 FREETEXT 查詢，則通?？床坏街麈I或排位值，但如果執(zhí)行 CONTAINSTABLE 或 FREETEXTTABLE 查詢，則將獲得這些值，然后這些值通常會(huì)與基表合并在一起。與基表合并主鍵的進(jìn)程需要很高的系統(tǒng)開(kāi)銷 稍后，我們將向您介紹一些巧妙的方法以盡量減少或完全避免這種合并。如果您通過(guò)不斷思考，對(duì)全文查詢?nèi)绾畏祷財(cái)?shù)據(jù)有了一個(gè)初步了解，就可以推測(cè)出 CONTAINS/FREETEXT 查詢僅執(zhí)行 CONTAINSTABLE/FREETEXTTABLE 查詢并與基表進(jìn)行合并。有了這樣的了解，您應(yīng)該避免使用這些類型的查詢，除非不這樣做的開(kāi)銷更高。在 Web 搜索應(yīng)用程序中，使用 CONTAINSTABLE 與 FREETEXTTABLE 比使用不帶 TABLE 的同類函數(shù)好得多。到現(xiàn)在為止，您已經(jīng)知道全文查詢是用來(lái)從 SQL Server 之外存儲(chǔ)的 MSSearch 索引中訪問(wèn)數(shù)據(jù)的特殊方法，還知道如果盲目地與基表進(jìn)行合并，就會(huì)遇到麻煩。應(yīng)該了解的另外一個(gè)重要內(nèi)容是 CONTAINS 樣式查詢與 FREETEXT 樣式查詢之間的本質(zhì)差別。CONTAINS 查詢用于對(duì)所查詢的所有詞語(yǔ)執(zhí)行完全匹配查詢。無(wú)論您只查找單個(gè)單詞，還是查找以“orange”開(kāi)頭的所有單詞，系統(tǒng)只返回包含所有搜索詞的結(jié)果。因此，CONTAINS 查詢速度很快，因?yàn)樗鼈兺ǔ７祷睾苌俚慕Y(jié)果，并且不需要執(zhí)行過(guò)多的附加處理。CONTAINS 查詢的缺點(diǎn)包括令人生厭的干擾詞過(guò)濾問(wèn)題。經(jīng)驗(yàn)豐富的開(kāi)發(fā)人員以及過(guò)去使用過(guò)全文搜索的數(shù)據(jù)庫(kù)管理員，在試圖匹配只包含單個(gè)干擾詞的單詞或詞組時(shí)，曾遇到過(guò)“您的查詢只包含干擾詞”這樣令人吃驚的錯(cuò)誤。要避免收到此錯(cuò)誤，方法之一是在執(zhí)行全文查詢之前過(guò)濾出干擾詞。向包含干擾詞的 CONTAINS 查詢返回結(jié)果是不可能的，因?yàn)榇祟惒樵冎环祷嘏c整個(gè)查詢字符串完全匹配的結(jié)果。由于干擾詞不是全文索引項(xiàng)，因此包含干擾詞的 CONTAINS 查詢不會(huì)返回任何行。FREETEXT 查詢消除了 CONTAINS 查詢中偶爾出現(xiàn)的所有警告說(shuō)明。當(dāng)發(fā)出 FREETEXT 查詢時(shí)，實(shí)際上發(fā)出的是詞根查詢。因此，當(dāng)您搜索“root beer”時(shí)，“root”和“beer”包含其所有形式（尋根溯源與語(yǔ)言相關(guān)；所用的語(yǔ)言由生成索引時(shí)指定的全文列語(yǔ)言確定，并且在所有查詢的列中必須相同），并且系統(tǒng)將返回至少與這些詞語(yǔ)之一匹配的所有行。FREETEXT 查詢的負(fù)面影響是它們通常比 CONTAINS 查詢耗用更多的 CPU 因?yàn)橐獙じ菰匆约胺祷馗嗟慕Y(jié)果，就需要包含更復(fù)雜的排位計(jì)算。不過(guò)，基于 FREETEXT 的查詢非常靈活，而且速度非?？?，是基于 Web 的搜索應(yīng)用程序中通常使用的最佳選擇。排位和優(yōu)化我經(jīng)常遇到使用全文搜索的用戶，他們問(wèn)我排位編號(hào)是什么意思，以及如何將排位編號(hào)轉(zhuǎn)換成某種用戶可以理解的值。對(duì)這個(gè)問(wèn)題，回答可長(zhǎng)可短，在這里我將進(jìn)行簡(jiǎn)要回答。簡(jiǎn)單而言，這些排位編號(hào)不如結(jié)果返回的順序那樣重要。也就是說(shuō)，當(dāng)您按照排位對(duì)結(jié)果進(jìn)行排序時(shí)，總是首先返回關(guān)聯(lián)程度最高的結(jié)果。排位值本身常常變化 全文搜索使用概率排位算法，即返回的每個(gè)文檔的關(guān)聯(lián)性受全文索引中的任何或所有其他文檔的直接影響。有些人認(rèn)為，一種有助于增加某些行排位的技巧是在這些行的全文索引列中重復(fù)常用的搜索關(guān)鍵字。盡管在某種程度上，這種方法可能會(huì)提高這些行因某些關(guān)鍵字而首先返回的幾率，但在其他情況下，可能會(huì)適得其反 而且還存在使詞語(yǔ)查詢性能降低的風(fēng)險(xiǎn)。較好的解決方案是為搜索應(yīng)用程序?qū)崿F(xiàn)“最佳選擇”系統(tǒng)（請(qǐng)參閱以下示例），這樣就可以確保首先返回某些文檔。多次重復(fù)使用關(guān)鍵字會(huì)使這些特定關(guān)鍵字的全文索引擴(kuò)大，并使得 MSSearch 在查找正確行和計(jì)算排位時(shí)浪費(fèi)時(shí)間。如果全文索引數(shù)據(jù)量很大，并嘗試使用了此方法，您可能會(huì)發(fā)現(xiàn)某些全文查詢很耗時(shí)。如果能夠?qū)崿F(xiàn)更細(xì)致（也可能更精確）的“最佳選擇”系統(tǒng)，您會(huì)發(fā)現(xiàn)它明顯改善了查詢性能。多次重復(fù)數(shù)據(jù)的另一個(gè)問(wèn)題與用于組合關(guān)系型查詢和全文查詢的常用技巧有關(guān)。許多使用全文搜索的用戶都深受此問(wèn)題的困擾，每當(dāng)他們?cè)噲D將某種過(guò)濾器應(yīng)用于全文查詢返回的結(jié)果時(shí)，便會(huì)遇到這樣的問(wèn)題。正如前面所說(shuō)的，全文查詢?yōu)槊總€(gè)匹配行返回一個(gè)主鍵和一個(gè)排位 要收集有關(guān)這些行的任何詳細(xì)信息，必須與它的基表進(jìn)行合并。由于從無(wú)限制的全文查詢中可能會(huì)返回任意數(shù)量的結(jié)果，因此合并可能需要大量系統(tǒng)開(kāi)銷。人們發(fā)現(xiàn)避免合并的一個(gè)有效方法是只在全文索引中添加要過(guò)濾的數(shù)據(jù)（如果可能）。換句話說(shuō)，如果用戶要從報(bào)紙上所有文章的正文中搜索關(guān)鍵字“Ichiro”，并且只希望返回該報(bào)上體育專欄中的文章，則查詢語(yǔ)句通常如下所示： [方法 1：] 開(kāi)銷最高：先全部選擇，然后再合并和過(guò)濾SELECT , , , FT_TBL.[rank] FROM FREETEXTTABLE(Articles, Body, 39。Ichiro39。) AS FT_TBLINNER JOIN Articles AS ARTICLES_TBLON FT_TBL.[key] = WHERE = 39。Sports39。 [方法 2：] 可以使用，但會(huì)導(dǎo)致意外結(jié)果并變慢，或者會(huì)返回不準(zhǔn)確的結(jié)果： 執(zhí)行全文過(guò)濾，并且只提取主鍵和排位 （處理在 Web 服務(wù)器上完成）SELECT [key], [rank] FROM CONTAINSTABLE(Articles, *, 39。FORMSOF(INFLECTIONAL(39。Ichiro39。) AND sports39。)這兩個(gè)查詢要么不必要地占用大量系統(tǒng)開(kāi)銷，要么存在返回錯(cuò)誤結(jié)果的可能性（在第二個(gè)查詢中，“sports”很可能出現(xiàn)在所有類型的文章中）。這兩項(xiàng)技術(shù)還存在其他變體，但這是兩種非常簡(jiǎn)單的模型。如果可行，我通常建議您對(duì)數(shù)據(jù)進(jìn)行水平劃分。即，“類別”列的每個(gè)可能值都自成一列（或表），并且與該文章相關(guān)的可搜索關(guān)鍵字僅存儲(chǔ)在此列中。采用此方法，而不是使用一個(gè)“正文”列和一個(gè)“類別”列，可以去掉“類別”列，而使用存儲(chǔ)可搜索關(guān)鍵字的“Body_category”列。如以下示例所示： 如果您可以調(diào)整架構(gòu)，這非常有效 ‐ 每個(gè)類別 都成為自己的列（或表格），并且需要命中的 全文索引也較少。這明顯需要作一些解釋……SELECT [key], [rank] FROM FREETEXTTABLE(Articles, Body_Sports, 39。Ichiro39。)對(duì)于包含大量數(shù)據(jù)，且這些數(shù)據(jù)可適應(yīng)此架構(gòu)（或許是主架構(gòu)）更改的系統(tǒng)，其性能會(huì)得到顯著的提高。但在何時(shí)應(yīng)用多個(gè)過(guò)濾器或不應(yīng)用過(guò)濾器方面卻有著明顯的限制。當(dāng)然，還有其他的方法可以解決這些問(wèn)題。通過(guò)以上示例，您會(huì)了解一種將某些搜索條件抽象到架構(gòu)的方法 實(shí)際上是“欺騙”優(yōu)化程序（更確切的說(shuō)是“成為”優(yōu)化程序），因?yàn)樵?SQL Server 本身的全文查詢中當(dāng)前不存在本地優(yōu)化。其他性能技巧人們?cè)诹奶鞎r(shí)常常問(wèn)我的另一個(gè)問(wèn)題是如何才能分頁(yè)顯示全文查詢結(jié)果。換句話說(shuō)，如果我要發(fā)出“root beer”查詢，一次在某一 Web 頁(yè)上顯示 40 個(gè)結(jié)果，并且只希望返回該頁(yè)面上的 40 個(gè)結(jié)果（例如，如果我在第三頁(yè)，我希望僅返回第 81 至第 120 條結(jié)果）。對(duì)于分頁(yè)顯示結(jié)果，我曾見(jiàn)過(guò)多種方法，但沒(méi)有一種方法能夠做到百分之百有效。我所推薦的方法可以最大程度地減少全文查詢執(zhí)行的次數(shù)（實(shí)際上，對(duì)于要分頁(yè)顯示的每個(gè)結(jié)果集只需執(zhí)行一次），并將 Web 服務(wù)器用作一個(gè)簡(jiǎn)單的緩存。從更高的層面來(lái)講，您只需在全文查詢中檢索一個(gè)完整的主鍵和排位值行集合（如果需要，可以在架構(gòu)中使用最佳選擇并提取常用過(guò)濾器），并將其存儲(chǔ)在 Web 服務(wù)器的內(nèi)存中（這取決于您的應(yīng)用程序和負(fù)載，想象將 32 字節(jié)的典型主鍵大小與 4 字節(jié)的排位大小相加 [等于 36 字節(jié)]，然后乘以通常返回的結(jié)果集 1000 行，最后等于 35K。假定一個(gè)在任何給定時(shí)間返回 1000 個(gè)活動(dòng)查詢結(jié)果集中的一個(gè)活動(dòng)緩存集，您將發(fā)現(xiàn)此活動(dòng)緩存集在