今天在google一個問題時，無意中看到了一個關於Lucene使用的連接，以前早聽過其大名，一直也沒有學習，只知道是個java開源的搜索引擎，今天既然看到一個連接，就點進去看了看，發現確實還有點意思，於是又google了幾篇文章看了看，特寫下一點自己的想法，算個小結。
本文並不涉及Lucene的具體使用。
首先我們來看像Lucene這樣的搜索引擎適用的地方。我現在的工作主要是一些j2ee的項目，有分佈式的，普通b/s的等，在這些系統中其實都用不着Lucene，因爲我也有數據要持久化，但這些數據都按字段分的比較小，要查詢，檢索之間用sql語句即可，改善性能可以在表中建索引，用存儲過程等方法。但換個項目場景，比如說一個論壇，它裏面可以發帖子，這些帖子也要持久化到數據庫中，等以後我要通過帖子內容的關鍵字來搜索帖子時，如果帖子內容是存在數據庫表的某個字段中，那這樣的查詢或搜索通過sql語句就幫不上忙了，這是像Lucene這樣的全文搜索引擎就可以幫上忙了，它實際上也是靠索引，只是這個索引是針對內容的，所以是脫離數據庫的。還有一點，我們對數據庫中的字段做精確查詢性能還可以，但做模糊查詢時性能下降很快，如like關鍵字的使用，而對於使用全文搜索的Lucene來說則主要可以解決這方面的問題。
像Lucene這樣的全文搜索引擎，它服務的對象是文本類文件，像.txt，xml文件等，所以我們要不數據庫中的數據先導成這樣的文本文件，如xml文件，然後利用Lucene對xml中的內容做索引，以後查詢直接查索引即可（如何建立索引是相當關鍵的，這也是各個引擎好壞的差別之一）。
總體上講，全文檢索和數據庫其實是2種根本不同的應用模式，全文檢索系統其實往往也沒有必要和數據庫那麼高的實時同步機制，如果按照低更新，高緩存的模式進行設計。數據庫數據到全文索引的同步過程一般都可以通過腳本定期將數據庫的數據導出成XML，然後進入Lucene的全文索引。而針對原有數據記錄的更新和刪除，其實一般可以通過定期的重建索引解決。所以我們在csdn中通過關鍵字來搜索相關的文檔時，找到了連接，但點擊去沒有文章了，因爲文章已經從數據庫中刪除了，但通過導出的文本文件建立的索引還沒更新，所以產生了這樣的問題。