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了。必须创建文章的时候才可以选择“原创、翻译”，让我有点小郁闷。呵呵，继续积硅步
！