在一個產(chǎn)品介紹網(wǎng)站中查詢產(chǎn)品時，由于產(chǎn)品的介紹性文字可能會很長，如果使用對產(chǎn)品介紹字段使用like進行模糊查詢，性能肯定會是問題。那么如何解決這個問題呢？第一個想法就是使用全文索引。那么全文索引是什么、應該如何應用、在應用的過程中又應該注意哪些事情呢？這個POST作為學習全文檢索的筆記。?
1、是什么?
????[摘錄自SQL?Server2000聯(lián)機從書]?
????全文索引為在字符串數(shù)據(jù)中進行復雜的詞搜索提供有效支持。全文索引存儲關于重要詞和這些詞在特定列中的位置的信息。全文查詢利用這些信息，可快速搜索包含具體某個詞或一組詞的行。?
????全文索引包含在全文目錄中。每個數(shù)據(jù)庫可以包含一個或多個全文目錄。一個目錄不能屬于多個數(shù)據(jù)庫，而每個目錄可以包含一個或多個表的全文索引。一個表只能有一個全文索引，因此每個有全文索引的表只屬于一個全文目錄。?
????全文目錄和索引不存儲在它們所屬的數(shù)據(jù)庫中。目錄和索引由?Microsoft?搜索服務分開管理。?
????全文索引必須在基表上定義，而不能在視圖、系統(tǒng)表或臨時表上定義。?
?????
????依據(jù)上面的描述，可以做這樣一個比喻。大家大概都見過檔案柜，檔案柜是將各種檔案按照分類登記在檔案索引卡上，這個檔案柜中的就象建立的全文索引，通過這些檔案索引卡可以迅速定位你要查找的卷宗所在的位置。如果不建立這些索引卡，如果卷宗數(shù)量不多還好，一旦檔案數(shù)量很多的時候顯然很難找到期望的卷宗，這就類似使用LIKE的情形。?
?????
????全文索引和普通索引的區(qū)別：??
普通SQL?索引??全文索引??
存儲時受定義它們所在的數(shù)據(jù)庫的控制?存儲在文件系統(tǒng)中，但通過數(shù)據(jù)庫管理?
每個表允許有若干個普通索引?每個表只允許有一個全文索引?
當對作為其基礎的數(shù)據(jù)進行插入、更新或刪除時，它們會自動更新?將數(shù)據(jù)添加到全文索引稱為填充，全文索引可通過調(diào)度或特定請求來請求，也可以在添加新數(shù)據(jù)時自動發(fā)生?
不分組?在同一個數(shù)據(jù)庫內(nèi)分組為一個或多個全文目錄?
使用SQL?Server企業(yè)管理器、向?qū)Щ騎ransact-SQL語句創(chuàng)建和除去?使用SQL?Server企業(yè)管理器、向?qū)Щ虼鎯^程創(chuàng)建、管理和除去?


2、怎么用??
????例子：參見使用SQL?Server2000的全文索引服務???
????上面這篇文章已經(jīng)說的比較清楚了，這里只是把典型的幾種SQL列出：??
????（詳細描述可以在SQL?Server2000聯(lián)機從書中查詢contains）?
????返回包含字符串?"sea"?或?"bread"?的所有分類描述。?
????Use?Northwind?
????Select?*?from?categories?
????where?contains(?description,?'?"sea*"?or?"bread*"?')?

????（詳細描述可以在SQL?Server2000聯(lián)機從書中查詢freetext）?
????搜索產(chǎn)品描述中含有與?bread、candy、dry?和?meat?相關的詞語的所有產(chǎn)品類別，如?breads、candies、dried?和?meats?等。?
????USE?Northwind?
????GO?
????SELECT?CategoryName?
????FROM?Categories?
????WHERE?FREETEXT?(Description,?'sweetest?candy?bread?and?dry?meat'?)?
????GO?

3、建議?
????a、仔細考慮維護全文索引的方式?
????[摘錄自SQL?Server2000聯(lián)機從書]?
????維護全文索引有三種方式：?

完全重建?
重新掃描所有行。徹底重建全文索引。既可以立即執(zhí)行完全重建，也可以通過?SQL?Server?代理按調(diào)度進行。?

基于時間戳的增量重建?
重新掃描那些從上一次完全重建或增量重建以來曾更改過的行。這樣做需要在表上有一?timestamp?列。不更新時間戳的更改（如?WRITETEXT?和?UPDATETEXT）是檢測不到的。可以立即執(zhí)行增量重建，也可以按調(diào)度進行。?

更改跟蹤?
維護一份對索引數(shù)據(jù)的全部更改的列表。用?WRITETEXT?和?UPDATETEXT?進行的更改是檢測不到的。可以用這些更改立即更新全文索引，也可以按調(diào)度進行，或者使用后臺更新索引選項在更改一發(fā)生時便更新。?

?????????所使用的方法取決于許多因素，如?CPU?和可用的內(nèi)存、數(shù)據(jù)更改的數(shù)量和速度、可用磁盤空間的大小，以及當前全文索引的重要性等。以下建議可作為選擇維護方式時的參考。?

當?CPU?和內(nèi)存不成問題，最新索引的值很高，且即時傳播可以跟得上更改的速度時，使用帶后臺更新索引選項的更改跟蹤。?


當?CPU?和內(nèi)存可以在調(diào)度時間使用，用于存儲更改的磁盤空間足夠大，且調(diào)度時間之間的變化并沒有大到使傳播所需的時間比完全重建更長時，使用帶調(diào)度傳播的更改跟蹤。?


如果大部分記錄的更改或添加是立即發(fā)生的，應該使用完全重建。如果大部分記錄是在擴展的時間段更改的，考慮使用帶調(diào)度或后臺更新索引的更改跟蹤。?


如果每一次更改的文檔數(shù)目很多（并不是所占的百分比很高），可以使用增量重建。如果大量記錄的更改是在擴展時間段發(fā)生的，考慮使用帶調(diào)度或后臺更新索引的更改跟蹤。???
????不過即使選擇好作業(yè)類型后，也應該給調(diào)度全文索引的時機進行恰當?shù)囊?guī)劃。由于表中數(shù)據(jù)的改變會影響全文索引內(nèi)容，所以頻繁的更新數(shù)據(jù)的表不太適合進行全文索引。同時可以把調(diào)度填充全文索引的時間放在系統(tǒng)比較空閑的時候，而且應該考慮到進行填充可能的時間。比如你可以把填充的時間定在每天晚上0:00，這個時候應該相對空閑一些（這個想法有些想當然的嫌疑，不過一般情況下應該差不多吧）。??
????另外應該模擬客戶處可能的數(shù)據(jù)量做個填充實驗，以便對填充索引的時間長度有所估計。??
??????
????啊~~全文檢索所涉及的面實在是太廣了。先整理這些吧~！??

總結

以上是生活随笔為你收集整理的SQL SERVER与ACCESS、EXCEL的数据转换的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。