【賽迪網-IT技術訊】先來看下影響索引的主要因素：
MaxMergeDocs
該參數決定寫入內存索引文檔個數，到達該數目后就把該內存索引寫入硬盤，生成一個新的索引segment文件。
所以該參數也就是一個內存buffer，一般來說越大索引速度越快。
MaxBufferedDocs這個參數默認是disabled的，因為Lucene中還用另外一個參數（RAMBufferSizeMB）控制這個bufffer的索引文檔個數。
其實MaxBufferedDocs和RAMBufferSizeMB這兩個參數是可以一起使用的，一起使用時只要有一個觸發條件滿足就寫入硬盤，生成一個新的索引segment文件。
RAMBufferSizeMB
控制用于buffer索引文檔的內存上限，如果buffer的索引文檔個數到達該上限就寫入硬盤。當然，一般來說也只越大索引速度越快。
當我們對文檔大小不太確定時，這個參數就相當有用，不至于outofmemory error。
MergeFactor
這個參數是用于子索引（Segment）合并的。
Lucene中索引總體上是這樣進行，索引現寫到內存，觸發一定限制條件后寫入硬
盤，生成一個獨立的子索引－lucene中叫Segment。一般來說這些子索引需要合并成一個索引，也就是optimize()，否則會影響檢索速度，
而且也可能導致open too many files。
MergeFactor 這個參數就是控制當硬盤中有多少個子索引segments，我們就需要現把這些索引合并沖一個稍微大些的索引了。
MergeFactor這個不能設置太大，特別是當MaxBufferedDocs比較小時（segment 越多），否則會導致open too many files錯誤，甚至導致虛擬機外面出錯。
Note: Lucene
中默認索引合并機制并不是兩兩合并，好像是多個segment
合并成最終的一個大索引，所以MergeFactor越大耗費內存越多，索引速度也會快些，但我的感覺太大譬如300，最后合并的時候還是很滿。
Batch indexing 應 MergeFactor>10
加快索引的一些技巧
• 確認你在使用最新的Lucene版本。
• 盡量使用本地文件系統
遠程文件系統一般來說都會降低索引速度。如果索引必須分布在遠程服務器，請嘗試先在本地生成索引，然后分發到遠程服務器上。
• 使用更快的硬件設備，特別是更快的IO設備
• 在索引期間復用單一的IndexWriter實例
• 使用按照內存消耗Flush代替根據文檔數量Flush
在Lucene
2.2之前的版本，可以在每次添加文檔后調用ramSizeInBytes方法，當索引消耗過多的內存時，然后在調用flush()方法。這樣做在索引大
量小文檔或者文檔大小不定的情況下尤為有效。你必須先把maxBufferedDocs參數設置足夠大，以防止writer基于文檔數量flush。但是
注意，別把這個值設置的太大，否則你將遭遇Lucene-845號BUG。不過這個BUG已經在2.3版本中得到解決。
在Lucene2.3之后的版本。IndexWriter可以自動的根據內存消
耗調用flush()。你可以通過writer.setRAMBufferSizeMB()來設置緩存大小。當你打算按照內存大小flush后，確保沒有
在別的地方設置MaxBufferedDocs值。否則flush條件將變的不確定（誰先符合條件就按照誰）。
• 在你能承受的范圍內使用更多的內存
在flush前使用更多的內存意味著Lucene將在索引時生成更大的
segment，也意味著合并次數也隨之減少。在Lucene-843中測試，大概48MB內存可能是一個比較合適的值。但是，你的程序可能會是另外一個
值。這跟不同的機器也有一定的關系，請自己多加測試，選擇一個權衡值。
• 關閉復合文件格式
調用setUseCompoundFile(false)可以關閉復合文件選項。生
成復合文件將消耗更多的時間（經過Lucene-888測試，大概會增加7%-33%的時間）。但是請注意，這樣做將大大的增加搜索和索引使用的文件句柄
的數量。如果合并因子也很大的話，你可能會出現用光文件句柄的情況。
• 重用Document和Field實例
在lucene 2.3中，新增了一個叫setValue的方法，可以允許你改變字段的值。這樣的好處是你可以在整個索引進程中復用一個Filed實例。這將極大的減少GC負擔。
最好創建一個單一的Document實例，然后添加你想要的字段到文檔中。同時復用添加到文檔的Field實例，通用調用相應的SetValue方法改變相應的字段的值。然后重新將Document添加到索引中。
注意：你不能在一個文檔中多個字段共用一個Field實例，在文檔添加到索引之前，Field的值都不應該改變。也就是說如果你有3個字段，你必須創建3個Field實例，然后再之后的Document添加過程中復用它們。
• 在你的分析器Analyzer中使用一個單一的Token實例
在分析器中共享一個單一的token實例也將緩解GC的壓力。
• 在Token中使用char[]接口來代替String接口來表示數據
在Lucene 2.3中，Token可以使用char數組來表示他的數據。這樣可以避免構建字符串以及GC回收字符串的消耗。通過配合使用單一Token實例和使用char[]接口你可以避免創建新的對象。
• 設置autoCommit為false
在Lucene
2.3中對擁有存儲字段和Term向量的文檔進行了大量的優化，以節省大索引合并的時間。你可以將單一復用的IndexWriter實例的
autoCommit設置為false來見證這些優化帶來的好處。注意這樣做將導致searcher在IndexWriter關閉之前不會看到任何索引的
更新。如果你認為這個對你很重要，你可以繼續將autoCommit設置為true，或者周期性的打開和關閉你的writer。
• 如果你要索引很多小文本字段，如果沒有特別需求，建議你將這些小文本字段合并為一個大的contents字段，然后只索引contents。(當然你也可以繼續存儲那些字段)
• 加大mergeFactor合并因子，但不是越大越好
大的合并因子將延遲segment的合并時間，這樣做可以提高索引速度，因為合并是
索引很耗時的一個部分。但是，這樣做將降低你的搜索速度。同時，你有可能會用光你的文件句柄如果你把合并因子設置的太大。值太大了設置可能降低索引速度，
因為這意味著將同時合并更多的segment，將大大的增加硬盤的負擔。
• 關閉所有你實際上沒有使用的功能
如果你存儲了字段，但是在查詢時根本沒有用到它們，那么別存儲它們。同樣Term向量也是如此。如果你索引很多的字段，關閉這些字段的不必要的特性將對索引速度提升產生很大的幫助。
• 使用一個更快的分析器
有時間分析文檔將消耗很長的時間。舉例來說，StandardAnalyzer就比較耗時，尤其在Lucene 2.3版本之前。你可以嘗試使用一個更簡單更快但是符合你需求的分析器。
• 加速文檔的構建時間
在通常的情況下，文檔的數據來源可能是外部（比如數據庫，文件系統，蜘蛛從網站上的抓取等），這些通常都比較耗時，盡量優化獲取它們的性能。
• 在你真的需要之前不要隨意的優化optimize索引（只有在需要更快的搜索速度的時候）
• 在多線程中共享一個IndexWriter
最新的硬件都是適合高并發的（多核CPU，多通道內存構架等），所以使用多線程添加文檔將會帶來不小的性能提升。就算是一臺很老的機器，并發添加文檔都將更好的利用IO和CPU。多測試并發的線程數目，獲得一個臨界最優值。
• 將文檔分組在不同的機器上索引然后再合并
如果你有大量的文本文檔需要索引，你可以把你的文檔分為若干組，在若干臺機器上分別索引不同的組，然后利用writer.addIndexesNoOptimize來將它們合并到最終的一個索引文件中。
• 運行性能測試程序
如果以上的建議都沒有發生效果。建議你運行下性能檢測程序。找出你的程序中哪個部分比較耗時。這通常會給你想不到的驚喜。