确定你真的需要加快速度。 这里的许多想法是简单的尝试，但其他人会有些复杂性必然添加到您的应用程序。所以要确保你的索引速度确实太慢，缓慢确实是在Lucene的。
请确保您正在使用Lucene的最新版本。
使用本地文件系统。 远程文件系统通常是用于索引相当慢一点。如果你的索引需要在远程fileysystem，考虑到本地文件系统首先构建它，然后将它复制到远程文件系统。
获取更快的硬件，尤其是更快的IO系统。 如果可能的话，使用固态硬盘（SSD）。这些设备在价格大幅回落近期，谋求低得多的成本可以在情况下，索引不能在操作系统的IO缓存完全满足一个非常可观的加速比。
打开一个作家和重新使??用它为您的索引会话的持续时间。
通过RAM使用，而不是文件计数冲洗。
对于Lucene的<= 2.2：调用writer.ramSizeInBytes（）每次添加文档后，再调用的flush（）它使用了太多内存时。如果你有小文档或高度可变文档的大小，这是特别好。你需要首先设置maxBufferedDocs足够大，以防止笔者从基于文件计数冲洗。但是，不要设置过大，否则你可能会碰到LUCENE-845。地方约2-3X你的“典型”刷新数应该没问题。
对于Lucene的> = 2.3：的IndexWriter可以根据RAM的使用本身冲洗。呼叫writer.setRAMBufferSizeMB（）来设置缓冲区的大小。可以肯定你不也有吃剩的调用setMaxBufferedDocs，因为作者将刷新“非此即彼”（以先到者为准）。
使用尽可能多的内存，你可以买得起。
冲洗前，更多的内存意味着Lucene的写大段开始这意味着更少的后来合并。测试在LUCENE-843发现，大约48 MB的是甜蜜点的内容设置，但你的应用程序可以有一个不同的甜蜜点。
关闭复合文件格式。
呼叫setUseCompoundFile（假）。构建复合文件格式需要时间建立索引期间（7-33％在测试LUCENE-888）。但是，请注意，这样做将大大增加使用的索引和搜索的文件描述符的数量，因此你可能会耗尽文件描述符，如果mergeFactor也大。
重新使用文档和字段实例 作为Lucene的2.3有新的setValue（...）方法允许你改变一个字段的值。这使您可以重新使用一个字段实例在许多添加的文档，它可以节省大量的GC成本。最好是建立一个单一的文件实例，然后添加多个字段实例，但守住这些现场情况，并通过改变它们的值对于每个添加的文档重新使用它们。例如，您可能有一个idField，bodyField，Name字段，storedField1等文件添加完成后，你再直接更改字段值（idField.setValue（...）等），然后重新添加您的文档实例。
请注意，您不能在文档中重新使用一个字段实例，并且，你不应该更改字段的值，直到包含该字段已被添加到索引的文件。见现场了解详情。
总是使用存储字段或词向量时，以相同的顺序字段添加到您的文件，
Lucene的合并具有一个优化据此存储域和词向量可以批量字节复制的，但优化仅适用于字段名- >数字映射是相同的跨段。Lucene的未来版本可能会尝试自动分配相同的映射（见LUCENE-1737），但在那之前得到相同的映射的唯一方法是随时添加以相同的顺序相同的字段，每个文档您索引。
在您的分析仪重新使用一个单一的令牌实例 分析仪通常用于创建在序列中的每个术语，需要从一个字段索引一个新的令牌。你可以通过重新使用单个令牌实例，而不是节省大量的GC成本。
使用令牌的的char [] API，而不是String的API来表示文字记号
作为Lucene的2.3的，一个令牌可以代表它作为一个切片文本到一个char数组，从而节省new'ing然后回收String实例的GC成本。通过重新使用单个令牌实例和使用char [] API，你可以避开new'ing每学期的任何对象。看到令牌的详细信息。
使用自动提交=假，当你打开你的IndexWriter
在Lucene的2.3有充分的优化使用存储域和词向量文件，以保存这些非常大的索引文件合并。您应该看到的最好的收益通过使用自动提交= false表示单个长时间运行的会话的IndexWriter。然而，搜寻者将不会看到任何由该刷新的变化注意的IndexWriter，直到它被关闭，如果是重要的，你应该坚持的autoCommit =真正的，而不是或定期关闭并重新打开该作家。
而不是索引很多小文本字段，聚集文成一个单一的“内容”字段，索引只是（你仍然可以存储其他字段）。
增加mergeFactor，但不会太大。
大mergeFactors推迟分部合并，直到后来，从而加快索引，因为合并是索引的很大一部分。然而，这会减慢搜索，而且，你将耗尽文件描述符，如果你使它变得太大。值过大，甚至可能会减慢索引，因为合并多个区段一次意味着更多的寻求硬盘驱动器。
关闭你是不是在实际上使用的任何功能。 如果要存储的字段，但不使用它们在查询时，不要将它们存储。同样，对于长期的载体。如果你是索引许多领域，关闭规范这些领域可能有助于提高性能。
使用更快的分析器。
有时候文件的分析需要大量的时间。举例来说，StandardAnalyzer是相当耗时的，尤其是在Lucene的版本<= 2.2。如果你可以通过与一个简单的分析，然后再尝试它。
加快建设文件。 经常检索从某处外部文件的过程（数据库，文件系统，从网站，抓取等）是非常耗时的。
不要优化... 永远。
使用多线程有一个的IndexWriter。 现代化的硬件是高度并行（多核CPU，多通道内存架构，原生指令在硬盘驱动器，排队等），所以使用一个以上的线程来添加文件，可以提供良好的收益整体。即使在较老的机器有很多时候还是并发IO和CPU之间的可以得到的。测试的线程数，以找到最好的性能点。
指数为单独的索引再合并。 如果你有一个非常大量的内容索引，那么你可以把你的内容分成N个“孤岛”，一个单独的机器上各指数料仓，然后使用writer.addIndexesNoOptimize将它们全部合并成一个最终的指数。
运行一个Java剖析。
如果一切都失败了，分析应用程序，以找出其中的时间是怎么回事。我有一个非常简单的剖析器称为成功的JMP。还有其他许多人。通常你会惊喜地发现一些无聊的，意想不到的方法是服用了太多的时间。
