SQL Server全文索引

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


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

    (詳細描述可以在SQL Server2000聯機從書中查詢freetext)
    搜索產品描述中含有與 bread、candy、dry 和 meat 相關的詞語的所有產品類別,如 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聯機從書]
    維護全文索引有三種方式:
  • 完全重建
    重新掃描所有行。徹底重建全文索引。既可以立即執行完全重建,也可以通過 SQL Server 代理按調度進行。
  • 基於時間戳的增量重建
    重新掃描那些從上一次完全重建或增量重建以來曾更改過的行。這樣做需要在表上有一 timestamp 列。不更新時間戳的更改(如 WRITETEXT 和 UPDATETEXT)是檢測不到的。可以立即執行增量重建,也可以按調度進行。
  • 更改跟蹤
    維護一份對索引數據的全部更改的列表。用 WRITETEXT 和 UPDATETEXT 進行的更改是檢測不到的。可以用這些更改立即更新全文索引,也可以按調度進行,或者使用後臺更新索引選項在更改一發生時便更新。
         所使用的方法取決於許多因素,如 CPU 和可用的內存、數據更改的數量和速度、可用磁盤空間的大小,以及當前全文索引的重要性等。以下建議可作爲選擇維護方式時的參考。
  • 當 CPU 和內存不成問題,最新索引的值很高,且即時傳播可以跟得上更改的速度時,使用帶後臺更新索引選項的更改跟蹤。

  • 當 CPU 和內存可以在調度時間使用,用於存儲更改的磁盤空間足夠大,且調度時間之間的變化並沒有大到使傳播所需的時間比完全重建更長時,使用帶調度傳播的更改跟蹤。

  • 如果大部分記錄的更改或添加是立即發生的,應該使用完全重建。如果大部分記錄是在擴展的時間段更改的,考慮使用帶調度或後臺更新索引的更改跟蹤。

  • 如果每一次更改的文檔數目很多(並不是所佔的百分比很高),可以使用增量重建。如果大量記錄的更改是在擴展時間段發生的,考慮使用帶調度或後臺更新索引的更改跟蹤。  
    不過即使選擇好作業類型後,也應該給調度全文索引的時機進行恰當的規劃。由於表中數據的改變會影響全文索引內容,所以頻繁的更新數據的表不 太適合進行全文索引。同時可以把調度填充全文索引的時間放在系統比較空閒的時候,而且應該考慮到進行填充可能的時間。比如你可以把填充的時間定在每天晚上 0:00,這個時候應該相對空閒一些(這個想法有些想當然的嫌疑,不過一般情況下應該差不多吧)。 
    另外應該模擬客戶處可能的數據量做個填充實驗,以便對填充索引的時間長度有所估計。 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章