向SQL Server全文索引進軍,艱難曆程

 

      寫這篇文章本來不在計劃之內，以前也沒有接觸過全文索引。偶然的一次備課中。突然有了靈感。決定將自己建立及其使用全文索引的過程記錄下來，以備後續使用。

至於全文索引的概念，網上一大堆，這裡就不再贅述。直接切入正題。

建立全文索引步驟：

1：對著資料庫點擊右鍵-選擇屬性-選擇檔案，選中“使用全文索引”

 

該選項只要勾選就可以了，預設都是勾選的。

2：對著表點擊右鍵-全文索引-定義全文索引

3：點擊下一步，如果這個表中沒有唯一性索引就會出現所示

 

4：選擇表列，選擇斷字元語言。

5：點擊下一步，這裡的選項要注意，如果不想再表、視圖更改的時候更新全文索引，那就選擇不跟蹤更改；這樣就可以選擇是否在建立索引時啟動完全填充了。

6：點擊下一步建立索引要儲存的目錄，全文索引的索引檔案是以檔案的形式儲存到硬碟上的。

7：之後就可以設定自動填滿、手動跟蹤更改，還有設定計划了。

上述步驟雖然簡單，但是我在建立時，碰到了N多問題

問題描述：

01．首先我對錶點擊右鍵的時候，全文索引功能表項目是灰色，不可用狀態

如

 

通過查詢資料發現需要執行如下命令開啟該功能表項目   

 EXEC sp_fulltext_database 'ensable'

這樣全文索引就變成可用狀態了。

如果想讓全文索引重新變暗(當然一般人不會這麼做)，可以執行如下代碼

 EXEC sp_fulltext_database 'disable'

02.在使用全文索引進行檢索時，必須要開啟全文檢索索引服務

 

預設該服務是關閉的。

03.當我建立好全文索引後，通過如下語句進行索引關鍵字時

Select content from info infoinfo

where contains(content, '但為了獲得最佳效能，建議使用主鍵約束或唯一約束。')

出現了如下提示：

"SQL Server 在與全文篩選器背景程式宿主(FDHost)進程通訊時遇到錯誤 0x80070218。請確保 FDHost 進程正在運行。若要重新啟動 FDHost 進程，請運行 sp_fulltext_service 'restart_all_fdhosts' 命令或重新啟動 SQL Server 執行個體。 "

經過反覆摸索, 發現需要在 SQL組態工具裡面, 更改全文檢索服務的運行賬戶, 有預設的 "系統內設"-->"本地賬戶", 搞定!

 

但是更改完該設定後，我依然沒能笑出聲來，原因是接下來雖然沒有錯誤發生，但是卻檢索不出我需要的結果，但通過like進行檢索，的確有資料。

select content from infoinfo

 where content like '%但為了獲得最佳效能，建議使用主鍵約束或唯一約束。%'

這時候，我差點崩潰了。沒辦法，繼續搜尋資料。

最後，從微軟官網上搜尋到這樣一篇文章

 

裡面詳細講述了產生該問題的原因，以及對應的解決方案

請注意

重要提示： 本文包含有關修改註冊表的資訊。 在修改註冊表之前，請務必對其進行備份，並確保您瞭解如何還原註冊表發生問題。有關如何備份、 還原，和編輯註冊表單擊下面的文章編號，以查看 Microsoft 知識庫中相應的文章：

256986Microsoft Windows 註冊表的說明

癥狀

具有 300 KB 以上的文本 （超過 150 KB ntext列的 UNICODE 文本） 的文本的啟用全文檢索功能的列上運行全文索引包含查詢時，您可能會收到一條訊息，"0 行受影響"，即使存在有效結果。

原因

Microsoft 搜尋服務 （MSSearch.exe） 維護 SQL Server 7.0 全文檢索搜尋來搜尋的基於字元的資料類型，如字元、 varchar、文本和ntext的全文檢索目錄。文本可以有多個 300 KB 的資料根據您定義的列 （ntext可以有多個 150 KB 的 UNICODE 文本）。全文索引填充時，MSSearch 服務從文本列中檢索所有非重複的單詞，並將它們儲存在虛擬記憶體中，它將它們合并到主索引之前。MSSearch 屬性可防止 MSSearch 服務佔用的虛擬記憶體。MSSearch 屬性由下面的註冊表和它的值控制：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0\Indexer\SQLServer\ <Full_Text_Catalog_Name> \ MaxBytesPerFile

例如: Full_Text_Catalog_Name = SQL0000500005
此登錄機碼的預設值設定為 307200 (300 KB)。因此，MSSearch 服務假定 300 KB 的文本作為重要和填充全文索引時將忽略文本列的其餘的資料。
因此，當您運行全文的 CONTAINS 子句查詢來搜尋後 300 KB 的文本將出現在文本欄中的單詞，不可能獲得有效結果。

替代方法

警告： 如果登錄編輯程式使用不當，可能會導致嚴重的問題，可能需要您重新安裝作業系統。登錄編輯程式使用不當所產生的問題，Microsoft 不能保證您可以解決。使用登錄編輯程式需要您自擔風險。
若要變通解決此問題：

1. 在開始菜單上，單擊運行
2. 鍵入 regedit，然後單擊確定
3. 在登錄編輯程式中找到下面的項：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0\Indexer\SQLServer\Full_Text_Catalog_Name\

（例如：
Full_Text_Catalog_Name = SQL0000500005）。

1. 單擊類型 REG_DWORD 的MaxBytesPerFile項。
2. 在編輯菜單上，單擊修改，然後指定根據您的要求的登錄機碼的數值資料。
3. 退出登錄編輯程式。
4. 重建全文檢索目錄。

但是真正按照這個文檔進行操作時，再次碰到了問題，就是第3步到1.0後，沒有Indexer檔案夾，我暈，只能再次硬著頭皮查資料。結果，網上資料很少，卻搜到一篇一模一樣的英文文章，是這樣寫的

PRB: A Full-Text Search Query on TEXT or NTEXT Column Does Not
Return Valid Results

Article
ID: 241113 - View products that
this article applies to.

This
article was previously published under Q241113

Notice

IMPORTANT: This article contains information about modifying the registry.
Before you modify the registry, make sure to back it up and make sure that you
understand how to restore the registry if a problem occurs. For information
about how to back up, restore, and edit the registry, click the following
article number to view the article in the Microsoft Knowledge Base:

256986

(http://kbalertz.com/Feedback.aspx?kbNumber=256986/EN-US/
)

Description
of the Microsoft Windows Registry

Expand all | Collapse
all

SYMPTOMS

When you
run a full-text CONTAINS query on a full-text enabled text column that has more than 300 KB of
text (more than 150 KB of UNICODE text for an ntextcolumn
), you may receive a "0 rows affected" message even though valid results
are present.

Back to the top | Give Feedback

CAUSE

The
Microsoft Search service (MSSearch.exe) maintains the full-text catalogs for
SQL Server 7.0 full-text search to search character-based data types such as char,varchar, text and ntext.
Columns that you define as text can have more than 300 KB of data (ntext can have more than 150 KB of UNICODE
text). When the full-text index is populated, MSSearch service retrieves all
the distinct words from the text column and stores them in the virtual
memory before it merges them into the master index. The MSSearch property
prevents the MSSearch service from consuming all the virtual memory. The
MSSearch property is controlled by the following registry and its value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0\Indexer\SQLServer\
<Full_Text_Catalog_Name>\ MaxBytesPerFile

For
example: Full_Text_Catalog_Name = SQL0000500005

The default value of this registry key is set to 307200 (300 KB). As a result,
MSSearch service assumes 300 KB of text as significant and ignores the
remaining data of the text column while it populates the
full-text index. 

Therefore, when you run a full-text CONTAINS clause query to search a word that
is present in the text column after 300 KB of text, you may
not obtain valid results.

Back to the top | Give Feedback

WORKAROUND

WARNING: If you use Registry Editor incorrectly, you may cause serious
problems that may require you to reinstall your operating system. Microsoft
cannot guarantee that you can solve problems that result from using Registry
Editor incorrectly. Use Registry Editor at your own risk. 

To work around this problem:

1. On the Start menu, click Run.
2. Type regedit,
   and then click OK.
3. Locate the
   following key in Registry Editor:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0\Indexer\SQLServer\Full_Text_Catalog_Name\

(for example:
Full_Text_Catalog_Name = SQL0000500005).

4. Click the MaxBytesPerFile key of type REG_DWORD.
5. On the Edit menu, click Modify, and then specify the Value Data of the registry key based on your
   requirement.
6. Quit Registry
   Editor.
7. Rebuild the
   full-text catalog.

     這裡列出該文章的目的，是為了後續使用（順便也來個英漢對照，學習下英文），當我看完時，突然想到一個問題，就是既然沒有Indexer檔案夾，我能不能手動建立一個呢？結果我一個一個檔案建立，最終建立出來的內容如

 

這裡我將文本最大大小設定成了30M。

然後刪除全文索引，從新建立後，一切都搞定。最終我看到了我要檢索的資料。

但是這裡有個問題，由於我資料庫中的資料量比較少，和like檢索效率無法對比，最後只能狂加資料，稍微能看出一點效果。

謹以此獻給耗時4個小時的自己。

     著作權（微冷的雨），請勿轉載，如轉載請註明出處 。

                                                                                                                  2013年6月15日星期六 上午