11.當IndexWriter處於open狀態時，請將autoCommit設置爲false
原文 寫道
In Lucene 2.3 there are substantial optimizations for Documents that use stored fields and term vectors, to save merging of these very large index files. You should see the best gains by using autoCommit=false for a single long-running session of IndexWriter. Note however that searchers will not see any of the changes flushed by thisIndexWriter until it is closed; if that is important you should stick with autoCommit=true instead or periodically close and re-open the writer.
Lucene 2.3 爲合併巨大的索引文件，對於儲存fields 和term vectors的Documents給與大量的優化措施。你應該發現在長期運行IndexWriter的情況下，將autoCommit設置爲false會取得最好的效率。注意，這時候的搜索將看不到任何改變，直到IndexWriter關閉。如果你需要添加的索引可以立刻被搜索到，你可以把autoCommit設置爲false，或者週期性的打開、關閉IndexWriter。
再看人家的翻譯：
在Lucene 2.3中對擁有存儲字段和Term向量的文檔進行了大量的優化，以節省大索引合併的時間。你可以將單一複用的IndexWriter實例的autoCommit設置爲false來見證這些優化帶來的好處。注意這樣做將導致searcher在IndexWriter關閉之前不會看到任何索引的更新。如果你認爲這個對你很重要，你可以繼續將autoCommit設置爲true，或者週期性的打開和關閉你的writer。
12. 原文 寫道
寫道
Instead of indexing many small text fields, aggregate the text into a single "contents" field and index only that (you can still store the other fields).
你可以將許多小的文本fields，聚合成一個文本並放到，放到一個"contents" field中。
再看人家的翻譯：
如果你要索引很多小文本字段，如果沒有特別需求，建議你將這些小文本字段合併爲一個大的contents字段，然後只索引contents。(當然你也可以繼續存儲那些字段)
這個要看需求吧，呵呵
13. 適當增大mergeFactor
原文 寫道
Increase mergeFactor, but not too much.
Larger mergeFactors defers merging of segments until later, thus speeding up indexing because merging is a large part of indexing. However, this will slow down searching, and, you will run out of file descriptors if you make it too large. Values that are too large may even slow down indexing since merging more segments at once means much more seeking for the hard drives.
合併因子越大意味着合格合併segments 越晚，這樣將會提高索引的速度，因爲合併在建立索引的時間中佔據了很大一部分。然而這種方式也將會見面搜索速度，同時如果你的索引很大的時候，你還很有可能用光你的文件句柄（爲什麼？？？？？![]()
）。合併因子太大也會適得其反的使索引變慢，因爲這意味一次將會合並更多的segments ，從而導致對硬盤的更多掃描。
其他翻譯：
大的合併因子將延遲segment的合併時間，這樣做可以提高索引速度，因爲合併是索引很耗時的一個部分。但是，這樣做將降低你的搜索速度。同時，你有可能會用光你的文件句柄如果你把合併因子設置的太大。值太大了設置可能降低索引速度，因爲這意味着將同時合併更多的segment，將大大的增加硬盤的負擔。
MegerFactor（合併因子）是控制segment合併頻率的，其決定了一個索引塊中包括多少個文檔，當硬盤上的索引塊達到多少時，將它們合併成一個較大的索引塊。當MergeFactor值較大時，生成索引的速度較快。MergeFactor的默認值是10，建議在建立索引前將其設置的大一些。
14. 關閉所有你不使用的功能
原文 寫道
Turn off any features（這裏翻譯成“功能”比較好） you are not in fact（實際，暈看成face了） using. If you are storing fields but not using them at query time, don't store them. Likewise for term vectors. If you are indexing many fields, turning off norms for those fields may help performance.
關閉所有你不使用的功能 。如果你現在存儲的fields在搜索時並不會使用他們，那麼請不要存儲他們。term向量也一樣。如果你索引了很多fields，關閉這些 fields 的norms 可以提高性能。
其他翻譯：
關閉所有你實際上沒有使用的功能 。如果你存儲了字段，但是在查詢時根本沒有用到它們，那麼別存儲它們。同樣Term向量也是如此。如果你索引很多的字段，關閉這些字段的不必要的特性將對索引速度提升產生很大的幫助。
15. 用更快的分析器analyzer
原文 寫道
Use a faster analyzer.
Sometimes analysis of a document takes alot of time. For example, StandardAnalyzer is quite time consuming（相當費時）, especially in Lucene version <= 2.2. If you can get by with a simpler analyzer, then try it
有時，分析一個文檔將會花費大量的時間。例如，標準分析器StandardAnalyzer 就相當耗時，尤其是在小於Lucene 2.2的版本下，如果你有一個更快的分析器，那麼用他吧（前提是符合你要求，呵呵）。
16. 加快文檔構建（Speed up document construction）
原文 寫道
Speed up document construction. Often the process of retrieving a document from somewhere external (database, filesystem, crawled from a Web site, etc.) is very time consuming.
加快文檔構建。從數據庫、文件系統、爬蟲……中索引文檔都是非常耗時的。
17. 在你真的需要之前不要隨意的優化optimize索引（只有在需要更快的搜索速度的時候）——（Don't optimize... ever.）
18. 多個線程同時使用一個IndexWriter（Use multiple threads with one IndexWriter）
原文 寫道
Use multiple threads with one IndexWriter. Modern hardware is highly concurrent (multi-core CPUs, multi-channel memory architectures, native command queuing in hard drives, etc.) so using more than one thread to add documents can give good gains overall. Even on older machines there is often still concurrency to be gained between IO and CPU. Test the number of threads to find the best performance point.
多個線程同時使用一個IndexWriter。如今的硬件是高併發的（多核cpu，多通道內存架構……），所以使用多線程add documents 話效果將會更好。即使在較老的機器上使用多線程也將會在IO和CPU上取得較好的效果。在實際環境中，你要通過實驗來確定線程個數，……
19.先分別建立幾個索引文件，最後在合併索引
原文 寫道
Index into separate indices(index的複數) then merge. If you have a very large amount of content to index then you can break your content into N "silos"(筒倉), index each silo on a separate machine,then use the writer.addIndexesNoOptimize to merge them all into one final index.
先分別建立幾個索引文件，最後在合併索引。如果你有打了的內容需要索引，你可以首先將這些內容分成“ 筒倉
”，然後分別有單獨的機器（有這必要，什麼情況下有這必要？）去對這些“ 筒倉
”建立索引，最後 writer.addIndexesNoOptimize調用合併這些索引。記得有個cms項目的索引就是這麼搞的，但可惜沒具體看效果，半死不活，非重點，唉![]()
。
20運行Java分析器(Run a Java profiler.)
原文 寫道
Run a Java profiler.
If all else fails, profile your application to figure out where the time is going. I've had success with a very simple profiler called JMP. There are many others. Often you will be pleasantly surprised to find some silly, unexpected method is taking far too much time.
如果以上所有方法都失敗了，你可以嘗試分析一下你的應用，找出來哪裏最花費時間。這裏給你推薦個即成功又簡單的分析器 JMP。當然也有很多其他的分析器。在分析之後，你通常會驚喜的發現一些可笑、……的方法花費了遠超預料的時間。
一點點的翻譯，不知不覺這一小節文章都跨年度了，今天已經是2012年1月9日14:37:56了。必須創建文章的時候纔可以選擇“原創、翻譯”，讓我有點小鬱悶。呵呵，繼續積硅步![]()
！
）。合併因子太大也會適得其反的使索引變慢，因爲這意味一次將會合並更多的segments ，從而導致對硬盤的更多掃描。
。
！