在一個產品介紹網站中查詢產品時,由於產品的介紹性文字可能會很長,如果使用對產品介紹欄位使用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 Agent按調度進行。
- 基於時間戳記的增量重建
重新掃描那些從上一次完全重建或增量重建以來曾更改過的行。這樣做需要在表上有一 timestamp 列。不更新時間戳記的更改(如 WRITETEXT 和 UPDATETEXT)是檢測不到的。可以立即執行增量重建,也可以按調度進行。
- 變更追蹤
維護一份對索引資料的全部更改的列表。用 WRITETEXT 和 UPDATETEXT 進行的更改是檢測不到的。可以用這些更改立即更新全文索引,也可以按調度進行,或者使用後台更新索引選項在更改一發生時便更新。
所使用的方法取決於許多因素,如 CPU 和可用的記憶體、資料更改的數量和速度、可用磁碟空間的大小,以及當前全文索引的重要性等。以下建議可作為選擇維護方式時的參考。
- 當 CPU 和記憶體不成問題,最新索引的值很高,且即時傳播可以跟得上更改的速度時,使用帶後台更新索引選項的變更追蹤。
- 當 CPU 和記憶體可以在調度時間使用,用於儲存更改的磁碟空間足夠大,且調度時間之間的變化並沒有大到使傳播所需的時間比完全重建更長時,使用帶調度傳播的變更追蹤。
- 如果大部分記錄的更改或添加是立即發生的,應該使用完全重建。如果大部分記錄是在擴充的時間段更改的,考慮使用帶調度或後台更新索引的變更追蹤。
- 如果每一次更改的文檔數目很多(並不是所佔的百分比很高),可以使用增量重建。如果大量記錄的更改是在擴充時間段發生的,考慮使用帶調度或後台更新索引的變更追蹤。
不過即使選擇好作業類型後,也應該給調度全文索引的時機進行恰當的規劃。由於表中資料的改變會影響全文索引內容,所以頻繁的更新資料的表不太適合進行全文索引。同時可以把調度填充全文索引的時間放在系統比較閒置時候,而且應該考慮到進行填充可能的時間。比如你可以把填充的時間定在每天晚上0:00,這個時候應該相對空閑一些(這個想法有些想當然的嫌疑,不過一般情況下應該差不多吧)。
另外應該類比客戶處可能的資料量做個填充實驗,以便對索引頁預留空間的時間長度有所估計。