ImproveIndexingSpeed精簡翻譯

    1.不會動您就別瞎動，確實是我的問題您再動，不然越動越亂。
   
    2.請及時更新至我的最新版本。

    3.使用本地磁盤，在遠程磁盤上訪問索引會慢，如果非要這麼幹，先在本地建好，再複製過去。

    4.有條件的話，就換固態硬盤。

    5.在索引的時候，複用單一的IndexWriter對象。

    6.使用基於內存量刷新磁盤，而不是使用基於文檔數目刷新磁盤。（注：這個在Lucene優化文檔中提到過）

    7.在承受範圍內多用內存，在Lucene-843測試中，48M是個比較合理的值（注：默認是16M）。

    8.關閉複合文件格式，調用IndexWriter.setUseCompoundFile(false)，雖然會增加建索引時間的7%-33%，但會增加搜索和索引時文件描述符的數量，如果mergeFactor設置過大，也會出現文件描述符用光的情況。（注：儘量還是不要搞這些東西）

    9.重用Document和Field對象，2.3版本中增加了setValue()的方法，可以改變一個Field的值，意味着可以只用一個Field就能構造出Document，可以節省GC開銷，最好的方式是用一個Document和幾個Field，通過setValue改變這些Field的值來不斷寫入Document。

    10.在分詞器中單例化Token類，分詞器會給每個詞條（Term）new一個Token，單例化可以節省GC開銷。

    11.在Token中使用char[]的API來代替String的API，在Lucene2.3，文本可以以char數組的形式來呈現，這樣可以節省GC開銷，結合上一條，單例化Token和改爲使用char數組的API。（注：我們認爲沒有必要玩的這麼深）

    12.在Lucene2.3中字段和向量的存儲得到了優化，節省了大索引合併的時間，你可以將單獨運行的IndexWriter上設置autoCommit=false，但是這樣做，在IndexWriter調用close之前，IndexSearcher將看不到新的變化。

    13.你想索引很多小的文本字段，可以先整合到一個大的文本字段裏再索引。

    14.增大mergeFactor參數，但別太高了。更大的mergeFactor會延遲segment的合併，可以提高索引速度。但是會減慢查詢，設太高了也會出現文件描述符用光的情況，設的過高也會降低索引速度，因爲合併過多的segment將會增加硬盤負擔。

    15.關閉你用不到的功能，如果你查詢時用不到原來的值，就不要Store，向量也是一樣。如果你存了很多字段，使用NO_NORM的選項也會有更好的表現。（注：和boost功能有關，在設置前要考慮清楚）

    16.使用更快的分詞器，例如2.3版本以前的StandardAnalyzer就很慢。

    17.加速Document的構建，它們常常來自於外部（數據庫，文件系統，來自網站的爬蟲的數據），先優化它們的獲取方式吧。

    18.在優化操作（optimize）之前要考慮清楚。（注：如果索引更新很頻繁就要考慮清楚是否要每次都優化）

    19.在多線程環境下使用一個IndexWriter對象，使用多線程來添加Document會帶來性能的提升。

    20.如果有大量的內容需要索引，可以先分爲若干組，在不同機器上索引，最後用IndexWriter.addIndexesNoOptimize來合併到最終的索引中。

    21.如果還有問題，可以使用性能檢測的工具，找出瓶頸。