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.如果还有问题，可以使用性能检测的工具，找出瓶颈。