“在合并内存索引器的索引到硬盘索引器前，务必先关闭内存索引器。”
于是我试着在前面加上"ramWriter.close();"，果然终于出现了久违的.cfs文件。
<2>上周在使用范围搜索时又遇到问题 ，程序抛出TooManyClauses exception。后来才发现lucene将范围搜索转化为精确匹配，每个匹配对应一个clause，所以如果你的范围如果包含超过1024个索引值，程序就会抛错
方案1：BooleanQuery.setMaxClauseCount(Integer.MAX_VALUE)改变限制，这个可以解决问题，但有隐患，如果某个范围的索引特别多，内存会有爆掉的危险。
方案2：使用filter
<3>目前索引里面已经有1000多万的数据了，现在需要每几分钟就增量得添加新的内容到索引中。但是，我发现新加入索引后，整个索引结构都要重新调整。非常耗时（长达半个小时）。不知道大家有没有什么比较好的办法，加快这个过程？
回答:
我觉得用lucene做，一个原则索引里面尽量少存储，索引文件小了，optimize要移动的数据块也小。
还有Lucene实在不适合做实时，有一个办法，将新索引建在内存中，新建在内存上的searcher与硬盘索引searcher合并为MutliSearcher提供给前端搜索，
内存到达一定量时再后台合并到主索引上，合并完成用新的Searcher替换MutliSearcher。
RAMDirectory和FSDirectory相结合使用
//创建基于RAMDirectory的索引
RAMDirectory rd = new RAMDirectory();
IndexWriter iw = new IndexWriter(rd,new StandardAnalyzer());
….
//向基于RAMDirectory的索引中添加文档
iw.addDocument(doc);
iw.close();
//建立基于FSDirectory的索引
FSDirectory fd = FSDirectory.getDirectory("mix");
IndexWriter writer = new IndexWriter(fd,new StandardAnalyzer());
//把缓存在RAMDirectory中的所有数据写入FSDirectory
writer.addIndexes(new Directory[] {rd});
writer.close();
//同样可以反过来用，将文件系统中的索引读入内存中，就需要使用如下的方法：
RAMDirectory rd=new RAMDirectory();
<4> 在大规模的应用中，Lucene更适合用于狭义的“搜索”，而不应当负责数据的存储。我们看看Lucene的源代码也可以知道，Document和Field的存储效率是不够好看的。手机之家的团队也发现了这一点，他们的办法是，用Lucene存放索引，用Memcache + Berkeley DB(Java Edition)负责存储。这样有两个好处，一是减小了Lucene的数据规模，提高了程序的效率；另一方面，这套系统也可以提供某些类似SQL的查询功能。实际上，Lucene Project自己似乎也注意到了这个问题，在Store中新增了一个db选项，其实也是利用的Berkeley DB。如果仅仅用Lucene存放索引，而不存放Document，并且合理配置，一台机器可以支持几十G甚至上百G的索引；如果需要用Lucene存放索引，最好在读取时使用FieldSelector，只读取需要的Field，如果使用恰当，性能会有10％左右的提升。
<5> 在大规模应用中，Cache是非常重要的。PPT中也提到，可以在程序提供服务之前，进行几次”预热“搜索，填充Searcher的 Cache。据我们（银杏搜索）的经验，也可以在应用程序中，再提供针对Document的Cache，这样对性能有较大的改善（同一个JVM内部的 Cache，速度更快一些）。Lucene自己似乎也注意到了这个问题，在2.4版本中提供了Cache，并提供了一个LRU Cache实现。不过据我们测试，在极端情况下，这个Cache可能会突破大小限制，一路膨胀最后吃光内存，甚至从网络上找的许多LRU Cache实现在极端条件下都有可能出现这样的问题（这也是我们百思不得其解的地方：反复检查程序的逻辑都没有问题），最终自己写了一个LRU Cache，并修改多次，目前来看是稳定的。
<6> 在编写Java服务程序的时候，记得设置退出的钩子函数（RunTime.getRunTime.addShutdownHook）是一个非常好的习惯。许多Java程序员都没有这种意识，或者有，也只是写一个finalize函数，结果程序非正常退出时，可能造成某些外部资源的状态不稳定。拿Lucene来说，之前的IndexWriter是默认autoCommit的，这样每添加一条记录，就提交一次，好处是如果中断，则之前添加的记录都是可用的，坏处则是，索引的速度非常低。在新版本中autoCommit默认为False，速度提升明显（我们测试的结果是，提高了大约8倍），但如果中途异常退出，则前功尽弃。如果我们添加了退出的钩子函数，捕获到退出信号则自动调用writer.close()方法，就可以避免这个问题。
<7> 目前的Lucene是兼容JDK 1.4的，它的binary版本也是JDK1.4编译的，如果对性能要求比较高，可以自行下载Lucene Source Code，用更新版本的JDK编译出.jar文件，据我测试，速度大约有30%的提升。
<8> 如果对并发的要求较高，可以考虑采用多IndexSearcher的技术，也就是在一个应用服务中，开启多个 IndexReader（可以对同样的索引开启多个），每个IndexReader再生成一个IndexSearcher，将这些Searcher放在一个“池”里头，给搜索请求调用。这样可以大幅度提高并发的性能，代价是在写程序的时候就要考虑到这一点，进行相应的调整。