Solr，Lucene 优化-CSDN博客

1. 从schema入手：
1> 你的数据是都需要store的么，比如一些字段只需要提供结果搜索而不作为结果返回，那么需要将store设置为false从而减少数据量。
2> 你的所有字段都需要highlight么，如果不需要highlight则可以将term vector关掉。
3> 确认你在schema没保存太多无用的信息（即不用来搜索也不用来返回）。
4> 你的分词算法是否合理，如果你使用的是ngram的分词方法，可以通过设置最大和最小分词长度来限制分词数据。
5> 你的业务上是否有明显的条目信息，比如你索引的东西是一本书，很多其他的信息在mysql或者其他地方有副本，这样的话，你大可以只store id信息，其他字段都不store。
6> 你的业务能不能拆分，比如之前书影音一起做搜索，你可以考虑将他们分开。

2. 从segment角度
1> lucence使用segment来保存索引数据，可以在Solr中通过mergeFactor来指定需要的临时文件数目，如果mergeFactor过大，则index的时间会缩短，但磁盘占用和搜索时间会变的很长，可以考虑适当调整mergeFactor，或者在slave上做定期的optimize操作， optimize会将segment合并到一起，当然，这个过程比较耗资源，所以可以考虑optimize的时候指定要merge到的数据。
2> 同样，在master ， slave环境中，最好不要在master上做optimize，因为在master上做optimize会导致slave每次复制整个index的数据，这当然不是你想要的，所以要采取措施不要让master和slave的配置一样，这样很不划算。

3. 从shard上
更一般的情况是，如果这些都不是你想要的，可以考虑shard， Solr支持很灵活的Shard，你可以在build index的时候给出规则让不同的数据发送到不同的服务器，比如同过hash等。这样你的大数据就可以分布在多个机器中，提高处理速度，当然，如果你有性能较好的机器，同样可以考虑在单一机器上做shard，利用多核的处理性能。但是要谨慎Solr的一些特性在Shard环境中的支持情况。

4. JDK
1> JDK 的版本，建议使用最新的版本，但是7貌似有bug，看有没有7.1， 32 vs 64 对java没影响，都是byte code ，不区分。
2> 可以通过制定Xmx Xms 参数调整heap 的大小，如果你经常出现heap over flow的话。
3> 启用多线程gc，这是你在处理大数据时避免溢出的好方法，一般一个core一个gc线程。

5. 设置适当的cache，根据cache命中率的不同来选择fastlru or lru。
这里网上有个叫做chenlb的人以前在1.4中做了一个patch，可以使用memcache做solr的cache，不过现在的3.5版本不兼容，作者也没有对其更新，如果你在分布式环境下，可以考虑自己做一下这个，弄好了可以分享给笔者。

6. 根据使用的不同，优化方式也非常的多，不再赘述。