硬體資源（例如記憶體、磁盤速度、CPU 速度和計算機體系結構）會影響全文索引和全文查詢的性能。導緻全文索引性能降低的主要原因是硬體資源的限制：
如果篩選器背景程式宿主程序 (fdhost.exe) 或 SQL Server 程序 (sqlservr.exe) 的 CPU 使用率接近 100%，則
CPU 會成為瓶頸。
如果平均磁盤等待隊列長度是磁盤頭數量的兩倍以上，則磁盤将成為瓶頸。主要的解決方法是建立獨立于 SQL Server
資料庫檔案和日志的全文目錄。将日志、資料庫檔案和全文目錄分别放在不同的磁盤上。購買運作速度更快的磁盤和使用 RAID 也能幫助改善索引性能。
如果實體記憶體不足（3GB 限制），則記憶體可能是瓶頸。實體記憶體限制可能存在于所有系統上，而在 32
位系統上，虛拟記憶體壓力可導緻全文索引速度降低。
注意：
從 SQL Server 2008 開始，全文引擎可以使用 AWE 記憶體，因為全文引擎是 sqlservr.exe 的一部分。
如果系統沒有硬體瓶頸，則全文搜尋的索引性能主要取決于以下因素：
SQL Server 建立全文批次花費的時間。
篩選器背景程式能以多快的速度處理這些批次。
與完全填充不同，增量、手動和自動更改跟蹤填充的設計目的并不是為了最大程度地利用硬體資源以獲得更高速度。是以，這些優化建議可能不會增強全文索引的性能。
填充完成後，将觸發最終的合并過程，以便将索引碎片合并為一個主全文索引。由于隻需要查詢主索引而不需要查詢大量索引碎片，是以這将提高查詢性能，并且可以使用更好的計分統計資訊來得出相關性排名。請注意，由于合并索引碎片時必須讀取和寫入大量資料，是以主合并可能會耗費大量
I/O，但它不會阻塞傳入的查詢。
重要提示：
對大量資料進行主合并會建立一個長時間運作的事務，在檢查點期間延遲事務日志的截斷。在這種情況下，事務日志可能會在完整恢複模式下顯著增長。作為最佳做法，在使用完整恢複模式的資料庫中重新組織較大的全文索引之前，應確定事務日志中包含足夠的空間用于長時間運作的事務。有關詳細資訊，請參閱。
若要最大限度地提高全文索引的性能，請實施下列最佳做法：
若要最大程度地使用所有處理器或核心，請将
‘<b>max full-text crawl ranges</b>' 設定為系統的 CPU 數。有關該配置選項的資訊，請參閱 。
請確定基表具有聚集索引。對聚集索引的第一列使用整數資料類型。避免在聚集索引的第一列使用
GUID。對聚集索引執行多範圍填充可以産生最高的填充速度。我們建議充當全文鍵的列采用整數資料類型。
使用
語句更新基表的統計資訊。更重要的是，更新聚集索引或全文鍵的統計資訊以進行完全填充。這有助于多範圍填充在表上生成良好的分區。
如果要提高增量填充的性能，請對 <b>timestamp</b> 列生成輔助索引。
在大型多 CPU 計算機上執行完全填充之前，建議您通過設定 <b>max server memory</b>
值來暫時限制緩沖池的大小，進而留出足夠的記憶體供 fdhost.exe 程序及作業系統使用。有關詳細資訊，請參閱本主題後面的“估計篩選器背景程式宿主程序
(fdhost.exe) 的記憶體需求量”。
若要診斷性能問題，請檢視全文爬網日志。有關爬網日志的資訊，請參閱。
如果對完全填充的性能不滿意，則建議按順序執行以下故障排除步驟。
在全文填充期間，fdhost.exe 或 sqlservr.exe 的記憶體有可能不足。如果全文爬網日志顯示 fdhost.exe
正在反複重新啟動，或系統傳回錯誤代碼 8007008，則意味着這些程序中的某一個程序記憶體不足。如果 fdhost.exe 在生成轉儲（特别是在大型多 CPU
計算機上），則該程序的記憶體可能不足。
若要獲得有關全文爬網所用的記憶體緩沖區的資訊，請參閱 。
可能的原因如下：
如果在完全填充期間可用的實體記憶體數量是零，則 SQL Server 緩沖池可能正占用系統的大部分實體記憶體。
sqlservr.exe
程序試圖侵占緩沖池的所有可用記憶體（最大為配置的最大伺服器記憶體）。如果配置設定的“最大伺服器記憶體”<b> </b>過大，fdhost.exe
程序可能會面臨記憶體不足的狀況及共享記憶體配置設定失敗。
在多 CPU 計算機（如 64 路 IA64 計算機）上進行全文填充期間，fdhost.exe 或 sqlservr.exe
之間可能出現緩沖池記憶體争用。由此造成的共享記憶體不足會導緻批次重試、記憶體抖動并讓 fdhost.exe 程序進行轉儲。
可以通過适當設定 SQL Server
緩沖池的“最大伺服器記憶體”<b> </b>值來解決此問題。有關詳細資訊，請參閱本主題後面的“估計篩選器背景程式宿主程序 (fdhost.exe)
的記憶體需求量”。減小用于全文索引的批次大小可能也會有用。
分頁問題
頁檔案大小不足也會導緻 fdhost.exe 或 sqlservr.exe
的記憶體不足，例如在具有增長受限的較小頁檔案的系統上。
如果爬網日志未訓示存在任何與記憶體相關的故障，則很可能是因為過度分頁導緻性能下降。
進行填充時 fdhost.exe 程序需要的記憶體量主要取決于它使用的全文爬網範圍數、入站共享記憶體 (ISM) 的大小以及最大 ISM
執行個體數。
可以使用下面的公式粗略估算篩選器背景程式宿主占用的記憶體量（以位元組為機關）：
number_of_crawl_ranges * ism_size *
max_outstanding_isms * 2
上面公式中的變量的預設值如下所示：
<b>變量</b>
<b>預設值</b>
number_of_crawl_ranges
CPU 的數目
ism_size
x86 計算機為 1 MB
x64 計算機為 4 MB、8 MB 或 16MB，具體取決于實體記憶體總量
max_outstanding_isms
x86 計算機為 25
x64 計算機為 5
下表列出了有關如何估算 fdhost.exe 的記憶體需求量的準則。此表中的公式使用以下值：
F，它是 fdhost.exe 所需記憶體的估計值 (MB)。
T，它是系統中可用實體記憶體的總量 (MB)。
M，它是最佳“最大伺服器記憶體”<b> </b>設定。
有關公式的基本資訊，請參閱下面的 1、2 和 3。
平台
估計 fdhost.exe 的記憶體需求量 (MB) - F1
用于計算最大伺服器記憶體的公式 - M2
禁用 AWE 的 x86
F <b>=</b> Number of crawl ranges <b>*</b> 50
M <b>=</b> <b>minimum</b><b>(</b>T<b>,</b> 2000<b>)</b>
<b>–</b> F <b>–</b> 500
啟用 AWE 的 x86
M <b>=</b> T <b>–</b> F <b>–</b> 500
x64 或 IA643
F <b>=</b> Number of crawl ranges <b>*</b> 10 <b>*</b> 8
M <b>=</b> T <b>–</b> F <b>–</b>
500
1 如果正在進行多個完全填充，則分别計算每個完全填充的 fdhost.exe 記憶體需求量，如
F1、F2 等等。然後按照 T <b>–</b> sigma<b>(</b>Fi<b>)</b>
計算得到 M。
2 500 MB 是系統中其他程序所需記憶體的估計值。如果系統正在執行其他工作，請相應地增加此值。
3 .ism_size 對于 x64 平台假定為 8 MB。
<b>示例：估計 fdhost.exe 的記憶體需求量</b>
此示例針對具有 8GM RAM 和 4 個雙核處理器的 AMD64 計算機。首先計算出 fdhost.exe 所需記憶體的估計值
F。爬網範圍數是 <code>8</code>。
<code>F = 8*10*8=640</code>
然後計算出“最大伺服器記憶體”<b> </b>的最佳值 M。 該系統的可用實體記憶體總量 (MB) T
是 <code>8192</code>。
<code>M = 8192-640-500=7052</code>
<b>示例：設定最大伺服器記憶體</b>
此示例使用 和
Transact-SQL 語句将“最大伺服器記憶體”<b> </b>設定為上一個示例中計算得到的 M 值，即
<code>7052</code>。
複制代碼
<b>設定最大伺服器記憶體配置選項</b>
我們希望當平均 CPU 占用率低于大約 30% 時完全填充的性能不是最佳的。本節讨論影響 CPU 占用率的一些因素。
長時間等待頁面
若要了解等待頁面的時間是否太長，請執行下面的 Transact-SQL 語句：
下表描述了這裡需要了解的等待類型。
等待類型
說明
可能的解決方法
PAGEIO_LATCH_SH（_EX 或 _UP）
這可能表明存在 IO 瓶頸，在此情況下通常還會發現平均磁盤隊列長度很高。
将全文索引移動到其他磁盤上的其他檔案組可能有助于減少 IO 瓶頸。
PAGELATCH_EX（或 _UP）
這可能表明多個正在試圖寫入相同資料庫檔案的線程之間存在大量争用現象。
将檔案添加到全文索引所在的檔案組可能有助于減輕此類争用。
有關詳細資訊，請參閱
。
掃描基表的效率很低
完全填充将掃描基表，以生成批次。在下列情況下，這樣的表掃描可能很低效：
如果基表有很高百分比的行外列正在建立全文索引，則掃描基表以生成批次可能成為瓶頸。在這種情況下，使用 <b>varchar(max)</b> 或
<b>nvarchar(max)</b> 對較小的資料進行行内移動可能有用。
如果基表非常零碎，掃描可能很低效。有關計算行外資料和索引碎片的資訊，請參閱 和 。
若要減少碎片，可以重新組織或重新生成聚集索引。有關詳細資訊，請參閱。
![JDBC連接配接資料庫（statement）[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)