很多人在使用lucene時會使用其提供的queryparser分析query。不過，lucene的queryparser從一開始到現在都沒有充分考慮中文等語言的特點，使得查詢中文會出現讓人不可理解的查不到結果的情況。這個bug就是LUCENE-2458。
這
個問題簡單說來就是，對于一個連續的中文query，queryparser將Analyzer返回的Term序列構成了PhraseQuery（也有可
能是MultiPhraseQuery），而PhraseQuery默認的匹配規則是要求Term序列在索引的文檔中完全順序匹配。這對于英文查詢來說是
可以接受的，因為queryparser在分析query時，首先通過AND、OR、NOT將query進行切分（這可以理解為queryparser
的第一層分析，這樣切分后構成的TOP
Query就是BooleanQuery），然后將切分后的subquery交由Analyzer分析（當然這要求是滿足FieldQuery的情況，否
則也可能是RangeQuery、WildcardQuery等），因為英文單詞之間以空格分割，相當于OR查詢，所以英文中的subquery就可以理
解是個短語（比如由多個連字符連接的短語，或者是英文和數字接合的短語，在lucene查詢語法中，顯示的雙引號之間的內容認為是短語）。但對中文來說，
如果將subquery分析成PhraseQuery，就很成問題。比如subquery是”諾基亞N97“，如果構成PhraseQuery，則要求索
引的文檔中必須存在”諾基亞N97“，如果”諾基亞“和”N97“中間有其他詞，就不算匹配。對于這個例子，是可以調整PhraseQuery的
slop參數來變相解決，但這種情況，使用AND
BooleanQuery更合適，使用BooleanQuery在對文檔打分上也要比PhraseQuery好很多。而對于query分詞結果，也存在一
些TermQuery之間是OR的情況，使用PhraseQuery顯然也不合適。
如LUCENE-2458提到，這個bug會在3.1和
4中被修復，修復方法是，只有顯示通過雙引號括起來的subquery才生成
PhraseQuery，否則可以派生子類來自定義處理。就目前使用來說，如果你使用IK做Analyzer，那么它提供的IKQueryParser是
很好的替代方案，它構造的就是由AND和OR聯合的BooleanQuery。但因為BooleanQuery沒有考慮各個Term在文檔中的位置關系，
一味的根據詞頻計算得分，檢索效果有時也不是很好。不知道大家是怎么處理的？我有想到去擴展它的Query和Scorer，不過看起來有些麻煩，暫且還沒
精力投入上去。