假設(shè)有這樣一個(gè)例子：在DataBase_name.dbo.Table_name中有一個(gè)名為Title(標(biāo)題)和Contents(內(nèi)容)的字段，現(xiàn)在需要查詢?cè)赥itle或者Contents中包括“qq”字符的所有記錄。

　　面對(duì)這樣的一個(gè)場(chǎng)景，我們通常都會(huì)寫這樣一個(gè)腳本：SELECT * FROM DataBase_name.dbo.Table_name WHERE Title LIKE '%qq%' OR Contents LIKE '%qq%'; 沒錯(cuò)，這也是我第一個(gè)想到的方法。但是我們需要思考的是：隨著時(shí)間的推移，數(shù)據(jù)會(huì)越來越大，那個(gè)時(shí)候我們?cè)撊绾翁岣呶覀兊男阅?用戶隨時(shí)都有可能再添加對(duì)Remark(備注)字段進(jìn)行查找，難道我們就應(yīng)該不厭其煩地修改程序代碼?

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

　　現(xiàn)在回到我們上面的問題，大概這個(gè)時(shí)候大家都應(yīng)該想到了數(shù)據(jù)庫(kù)的全文索引了。全文索引是一種特殊類型的基于標(biāo)記的功能性索引，由 Microsoft SQL Server 全文引擎 (MSFTESQL) 服務(wù)創(chuàng)建和維護(hù)。創(chuàng)建全文索引的過程與創(chuàng)建其他類型的索引的過程差別很大。MSFTESQL 不是基于某一特定行中存儲(chǔ)的值來構(gòu)造 B 樹結(jié)構(gòu)，而是基于要索引的文本中的各個(gè)標(biāo)記來創(chuàng)建倒排、堆積且壓縮的索引結(jié)構(gòu)。

　　為什么說SQL Server 全文索引不是萬(wàn)能的?就是這個(gè)全文索引能解決我們一開始提到的場(chǎng)景嗎?回答是否定。為什么呢?因?yàn)樗�的分詞和倒排索引造成了對(duì)字符串“tqq.tencent.com”這樣的內(nèi)容進(jìn)行‘“*qq*”’這樣的條件查詢，上面那條記錄是不會(huì)被返回的。它的分詞應(yīng)該是正向最大值的分詞方法，它沒有對(duì)方向再進(jìn)行一次分詞和索引，索引無法查詢到。這個(gè)可能會(huì)被大家所忽略掉的。