全文檢索允許在 Microsoft® SQL Server&#
;
表內對字符數據進行基於單詞或短語的索引
全文檢索由下面的基本組
件組成
全文索引啟用了全文目錄的創建和填充
它們在 SQL Server 以外維護並且由 Microsoft 搜索服務管理
全文檢索使用新的 Transact
SQL 謂詞（CONTAINS
CONTAINSTABLE
FREETEXT 和 FREETEXTTABLE）來查詢這些已填充的
全文目錄
全文索引
如果正在對不到一百萬行的表進行全文索引
那麼幾乎不需要進行性能優化
如果對大型 SQL Server 表（其中包含創建
大型全文目錄的上百萬行）進行全文索引
那麼這會持續進行大量的讀取和寫入活動
因此必須配置 SQL Server 和全文
目錄
以通過跨多個硬盤驅動器進行負載平衡來獲得最優磁盤 I/O 性能
同時還需要考慮硬件配置
Microsoft
Windows®
或 Windows NT®
系統配置
SQL Server
配置
全文目錄和數據庫文件的實際位置
硬件考慮事項
多個 CPU
一到四個
MHz Xeon III 處理器
內存
到
GB 的物理 RAM
具有幾個通道的多磁盤控制器
或具有多通道的單磁盤控制器
磁盤 I/O 子系統
RAID
（沒有容錯保護的磁盤條帶化）
RAID
+
和 RAID
Windows
或 Windows NT
系統配置的考慮事項
如果在 Windows NT Server
上安裝 SQL Server
那麼 pagefile
sys 文件的大小需要設置為可用物理 RAM 量的
到
倍
在有較大 RAM 量的 Windows
Server 上安裝 SQL Server 時
可以不用考慮這一條
Pagefile
sys 文件需要放置在它們自己的驅動器（RAID
或 RAID
+
）上
最好在單獨的控制器或至少是與共享控制器分
離的單獨通道上
SQL Server 配置的考慮事項
在大型表（超過一百萬行）中進行完全填充後
考慮將新特性 Change Tracking 與 Update Index in Background 和
Update Index 對 Incremental Population 一起使用
有關何時使用 Change Tracking 對 Timestamp
based
incremental 填充的更多信息
請參見維護全文索引
全文索引和目錄考慮事項
全文索引或填充全文目錄應該在系統活動較少時進行
通常在數據庫維護窗口完成
將全文目錄文件放置在它自己的磁盤控制器上
或有多個通道的單個磁盤控制器上單獨的通道中
將數據庫文件放置在與全文目錄文件不同的獨立的磁盤控制器上
或有多個通道的單個磁盤控制器上單獨的通道中
具有四百萬或兩千萬行的 SQL 表的全文索引可能要花費幾個小時或幾天來完成
考慮知識庫文章 Q
中提供的選
項
INF
如何移動
復制和備份 SQL
全文目錄文件夾和文件
全文檢索
如果正在對不到一百萬行的表進行全文檢索
那麼幾乎不需要任何性能優化
（一百萬行只是常規的分界點
）如果要對
超過一百萬行的表進行全文檢索
請考慮適當的全文檢索謂詞（CONTAINS 與 CONTAINSTABLE 或 FREETEXT 與
FREETEXTTABLE）以及平均行數和查詢超時的考慮事項
使用帶有新的 top_n_by_rank 參數的 CONTAINSTABLE 或 FREETEXTTABLE 來限制返回的行數
top_n_by_rank 指定只返回
以降序排列的前 n 個最高等級的匹配項
僅當指定了整數值 n 時應用
另外
應該考慮使用 TOP 子句來限制在
CONTAINTSTABLE 或 FREETEXTTABLE 的結果集中返回的行數
請查閱知識庫文章 Q
FIX
通過支持 TOP 改善全文
檢索性能
以獲得更多信息
如果試圖通過附加的 WHERE 子句限制從全文查詢得到的結果
那麼 WHERE 子句是在與 SQL 表結果聯接 (JOIN) 之後而非
之前應用
否則
結果集會不正確
因為合格的行會從結果集中省略掉
而沒有任何對客戶端的提示
若要限制全文檢索
查詢的結果
請使用 CONTAINSTABLE 或 FREETEXTTABLE 謂詞中的 Top_N_Rank 參數
如果通過 Web 或 Microsoft Internet Information 服務 (IIS) 接口使用 SQL Server 全文檢索
並且正在搜索大型表
（超過一百萬行）
那麼當使用 CONTAINS 或 FREETEXT 謂詞時
請考慮將 IIS 查詢超時默認值增加
秒到
秒
如果在 SQL 查詢中使用多個 CONTAINS 或 FREETEXT 謂詞
並發現全文檢索查詢性能較差
請減少 CONTAINS 或
FREETEXT 謂詞的數量
或使用
*
在查詢中使用所有全文索引列
在全文查詢中使用任何一個全文謂詞時
例如 CONTAINS (pr_info
between AND king
)
還可能遇到錯誤
查詢
只包含忽略的單詞
單詞
between
是一個忽略詞或干擾詞
即使帶有 OR 子句
全文查詢語法分析器也會將其視為一個
錯誤
考慮將查詢重新寫為基於短語的查詢並刪除干擾詞
或考慮知識庫文章 Q
中提供的選項
INF
正確分析
FTS 查詢中的引號
還請考慮使用 Windows
Server
它對索引服務的斷詞文件有一定增強
什麼是 RANK 以及當與 CONTAINSTABLE 和 FREETEXTTABLE 謂詞一起使用時如何確定 RANK？全文 RANK 值是根據包含唯一
詞的行出現的頻率確定的
在確定返回行的 RANK 值中發揮作用的一個因素是這個唯一詞在該行的全文索引列中出現的頻
率
另一個因素是唯一詞在表中出現的總次數（這用於規范化概率）
結果集中返回的 RANK 值是互相關聯的
因此
不
可能將 RANK 值解釋為百分比
或將 RANK 值分組為高/中/低范圍
請將 RANK 視為一種對特定查詢和結果集排序的方
法
當確定是在一個全文目錄中包括多個 SQL 表
還是每個全文目錄一個 SQL 表時
還有一些全文索引和檢索的考慮事項
當考慮大型 SQL 表的這種設計問題時
在性能和維護之間應進行權衡
而您可能希望對您的環境測試這兩種選項
如果選
擇在一個全文目錄中有多個 SQL 表
則會因運行全文檢索查詢時間較長而帶來開銷
因為增量填充會強制所有其它 SQL
表的全文索引都放在該全文目錄中
如果選擇每個全文目錄具有一個單獨的 SQL 表
並對多個 SQL 表進行全文索引
就
會引起維護單獨的全文目錄的開銷（每個服務器總共只能有
個全文目錄）
From:http://tw.wingwit.com/Article/os/xtgl/201311/9141.html
