確認你在使用Lucene的最新版本
- 儘量使用本地文件系統
遠程文件系統一般來說都會降低搜索速度。如果索引必須分佈在遠程服務器，可以嘗試將遠程文件系統設置爲只讀。在某些情況下，這樣可以提高性能。
- 使用更快的硬件設備，特別是更快的IO設備
Lucene搜索可以很好的工作在基於閃存的固態硬盤上。固態硬盤的尋道時間大概比傳統的以磁盤爲基礎的硬盤快100倍。這意味着，配備固態硬盤的機器用於文件緩存的內存將變少，搜索需要較少的熱身時間，能夠更加迅速作出反應。
- 加大你的機器內存容量，給Java虛擬機分配更多的內存
索引越大，在搜索時需要使用更多的內存。如果你的機器沒有足夠大的內存或者你的Java虛擬機沒有設置足夠大的堆空間，頻繁的頁面文件交換和虛擬內存的使用將使你的硬盤處於超負荷狀態運行，此時，一切的程序都將運行的很慢。
- 在程序中使用一個唯一的IndexSearch實例
在程序的查詢中共享一個IndexSearch實例，它支持多線程安全。
- 當測試搜索速度時，忽略第一次查詢時間
第一次搜索將花費部分時間在緩存上（特別在按某個字段排序的情況下），從而可能使你的測試結果不太準確（假設你在多個查詢中複用一個IndexSearch實例）。另一方面來說，如果你一次又一次的重複同一個查詢，所得的測試結果也是不準確的。因爲操作系統將利用其高速緩存加速IO操作。在Linux上，你可以使用如下命令清除磁盤高速緩存：
echo 3 > /proc/sys/vm/drop_caches.
- 只有在必要的時候才重新構造IndexSearcher
爲了獲得更新的索引信息，你必須重新構造IndexSearch。當然，重新構造一個searcher會帶來一定的系統開銷（注意，這大多發生在大索引以及自定義排序上），所以你應該儘量減少重新構造。你可以考慮在重新構造之後強制進行一次搜索預熱。
- 在搜索之前調用optimize優化你的索引
一個優化後的索引只含有一個Segment（其實說法不嚴謹，這也取決於一個Segment最多含有的文檔參數），這將比同等情況下含多個Segment的索引搜索速度更快。特別是在大索引的情況下。如果你的程序不經常更新索引，那麼花費一定的時間來優化下，然後使用優化後的索引來進行搜索。如果你的索引更新的頻率很高，那麼優化索引將會是一個很耗時間的事情，這個時候你可以減少mergeFactor參數。
個人建議，在頻繁更新索引的情況下，使用兩個索引，一個大的優化好的歷史索引，一個小的實時添加的索引（如果數據不大的情況下，直接使用RAMDirectory，然後定時的合併到大索引中）
- 減小MergeFactor合併因子的值
更小的合併因子意味着索引中擁有更少的Segment，搜索速度也將更快。但是，這也將降低索引速度。你需要自己測試一個值來平衡二者的關係。（此條只適用於不能經常優化的索引庫）
- 限制存儲字段的使用以及獲取儘可能少的數據
從索引中獲取數據是一件很耗時間的事情，你最好只獲取用戶需要的數據。而不是整個文檔中存儲的數據。每個文檔的取回，lucene都必須去索引文件中不同的地方甚至是不同的文件中查找。可以嘗試將你需要的文檔先按文檔編號排序再獲取。
- 當你取回文檔時，使用FieldSelector仔細的選擇哪些字段需要獲取，如何獲取。
- 不要獲取多於你需要的hits
獲取更多的搜索結果將會降低搜索速度。有兩個原因：其一，search方法在返回Hits對象時，如果超過100個hits，lucene將在內部自動重新執行搜索。解決方案：使用返回HitCollector的Search方法。其二，搜索結果可能分佈在硬盤的不同地方，獲取他們可能需要很多的IO操作。這個是很難避免的，除非索引比較小，可以直接緩存到內存當中。如果你不需要完整的文檔對象，你只需要其中的一個很小的字段，你可以使用FieldCache類來緩存它，從而達到快速訪問的效果。
- 當使用 fuzzy 查詢時設置一個較小的比較長度 （prefixLength）
Fuzzy查詢執行CPU密集型字符串比較，儘量避免將用戶查詢的Term與所有的 Term進行比較。你可以設置只比較以前N個字符開頭的Term。prefixLength在QueryParser以及FuzzyQuery中可以設置。默認值爲0，將比較所有的Term。
- 考慮使用filters
有時候我們的查詢將限制部分索引中的記錄，這時候使用一個經過緩存了的bit set filter將比使用查詢子句更有效，尤其在一個大索引中。過濾器經常用在查詢分類結果上。它可以用查詢子句限制來替換，區別在於使用Query將影響文檔的得分，而Filter不會。
