下面假設有這樣一個例子：在DataBase_name.dbo.Table_name中有一個名為Title(標題)和Contents(內容)的字段，現在需要查詢在Title或者Contents中包括“qq”字符的所有記錄。

　　面對這樣的一個場景，我們通常都會寫這樣一個腳本：SELECT * FROM DataBase_name.dbo.Table_name WHERE Title LIKE '%qq%' OR Contents LIKE '%qq%'; 沒錯，這也是我第一個想到的方法。但是我們需要思考的是：隨著時間的推移，數據會越來越大，那個時候我們該如何提高我們的性能?用戶隨時都有可能再添加對Remark(備注)字段進行查找，難道我們就應該不厭其煩地修改程序代碼?

　　需要指出的是：面對這樣的查詢條件，即使Title和Contents上都有索引，我們也無法使用到索引，因為在 '%qq%'的“qq”前面使用了通配符，所以無法使用到索引;如果查詢的條件是'qq%'，那到是可以利用上索引。在許多數據庫性能調優的文章上都說OR這個謂詞可以使用SELECT UNION ALL SELECT這樣的方式來提高性能，但是需要提醒大家的是：如果在一條記錄中字段Title和Contents都同時存在“中國”字符的話，那么返回的結果就會出現兩條相同的記錄，如果你希望是唯一的記錄，那么這個時候你就要注意了。

　　現在回到我們上面的問題，大概這個時候大家都應該想到了數據庫的全文索引了。全文索引是一種特殊類型的基于標記的功能性索引，由 Microsoft SQL Server 全文引擎 (MSFTESQL) 服務創建和維護。創建全文索引的過程與創建其他類型的索引的過程差別很大。MSFTESQL 不是基于某一特定行中存儲的值來構造 B 樹結構，而是基于要索引的文本中的各個標記來創建倒排、堆積且壓縮的索引結構。(摘自MSDN)

　　為什么說SQL Server 全文索引不是萬能的?可能大家都懷疑我是不是標題黨了，呵呵，馬上就講到，那就是這個全文索引能解決我們一開始提到的場景嗎?回答是否定。為什么呢?因為它的分詞和倒排索引造成了對字符串“tqq.tencent.com”這樣的內容進行‘“*qq*”’這樣的條件查詢，上面那條記錄是不會被返回的。它的分詞應該是正向最大值的分詞方法，它沒有對方向再進行一次分詞和索引，索引無法查詢到。這個可能會被大家所忽略掉的。