SQL Server 的全文檢索

從 MySQL 將資料轉到 SQL Server 後，接下來當然就是嘗試全文檢索的功能。

大致上，效能果然比 MySQL 好上許多（大約有十倍以上的效能提升吧）。這或許可以說明，MySQL 的全文檢索，可能只是「虛晃一招」，沒有好好認真去做。

即使是檢索「劉銘傳」，回傳 2407 篇文件也不會吃掉太多效能。但... 等等，印象中，在 MySQL 下用「海山口」來查詢，會取得 25 篇文件，但 SQL Server 怎麼只檢索出 23 篇？

雖然頗覺事有蹊蹺，但又有些懶：既然只是 prototype，這又頗明顯是 SQL Server 的問題，況且「大多數的查詢結果與 MySQL 的查詢結果是相同的」，不講大概也沒有人會發現。那麼，「假裝沒看到」又何妨？

不過，隔了一陣子還是忍耐不住，想了解究竟是怎麼回事。（哎，這該算是個性上的優點還是缺點多啊？）

最先浮上心頭的想法，是懷疑「海山口」的前後文，是否在 big-5 或者 unicode 中，含有特殊的字元；而這樣的字元，導致 SQL Server 在做全文索引時弄錯了。調出一篇沒有被檢索出來的文件，相關內容是這樣的：

...比臺北海山口最上之米。一石僅低十錢...

嗯，看起來好像沒有什麼問題？

這下子有點傷腦筋了。懷疑是否 SQL Server 的全文檢索有參數可以設定。然而，搜尋網路與相關文件後，卻只找到 stop words 的檔案；但即使將 stop words 通通拿掉，也還是檢索不出這篇文件。

不信邪，用「海山」找找看。喔，可以找到數百筆資料，但怎麼就是不含這一篇？改用「山口」試試看好了 --- 咦，這回可以檢索到耶。這究竟是怎麼回事啊？

嘗試了一些查詢後，我覺得 SQL Server 好像把「北海」「山口」斷詞斷開（當成是兩個片語）了。想到前同事 Tim 曾提到，Microsoft Word 有類似的斷詞判斷能力，就把上面框起來的那些字拷貝到 Word 裡...

結果還真的頗有趣。當我在「北」或者「海」上頭 double click 時，Word 會 highlight 選出「北海」，在「山」或「口」上雙按，則會選出「山口」。看來，Microsoft 在 Windows 的某個地方，確實有個「斷詞」的程式模組，而 SQL Server 的全文檢索，則「笨笨地」誤用斷詞了。

找不到如何取消這類「自作聰明」舉動的地方，只好用類似於在 MySQL 上檢索中文的方式，在每個中文字間，加上空白，然後用「片語檢索」的方式，查詢 "海 山 口" （在字與字之間加上空白）--- 這下終於成功地檢索出 25 篇文件了。

實作中文系統就是這樣，常常會遇到一堆莫名其妙的問題。為了交差，有時就難免得用到 work around 的解決方式；而既然是折衝繞路後的解決方案，深層根本的問題也就比較多。我想，這應該也部分說明了，為什麼中文的系統，（比單純的英語系統）感覺起來經常是「問題一籮筐」吧。