? 在此之前，我始终任务，forceMerge会带来更好的检索效果，能够大幅度提升检索的性能。因为forceMerge能够减少底层检索文件的个数。将M个小文件的IO，转变为一个文件的IO。
? 但是今天看到了这篇文章，让我有了新的理解和认识，并不是合并的越少越好。还要分情况讨论。还要考虑到缓存的影响。原文：forcemerge，类型选择和 oom | easyice
通常我们认为一个 LSM 架构的系统，其文件数量 merge 到更少总会带来查询性能的提升，但Elasticsearch 和 lucene 确实有他的复杂之处，最近遇到一个案例，当索引 forcemerge 为 1 之后其查询延迟和查询 QPS都降低了，主要原因是， forcemerge 之后，查询语句构建 query cache的代价更大。
这个特殊场景是查询语句的 lead 子查询只在少数段上有命中。 绝大多数段上无命中，因此 leadCost 为 0，可以跳过构建 query cache 的过程。而 merge 为 1 之后 lead 条件必然是有命中的，有更大的几率要去构建 query cache。
可以跳过构建 query cache 的依据是子查询的 cost 除以 250 大于 leadCost，当 leadCost为 0 自然就不再构建了。
题外话：在 query cache 的 skip 机制是个很好的策略，但250并不适用所有场景，目前 Elasticsearch 没有可以调节的接口
另一种极端情况是 merge 为 1 之后文件数少了，如果有很高的并发读取单一的段文件，niofs 由于各线程使用同一个 FileChannel读文件，其线程安全特性会导致很多线程在等锁，但这种情况比较少见。
要确定一个查询语句是否只在少数分段有命中比较困难，如果你想要 forcemerge 的话，在现有机制下可以考虑两种方式可以避免这个问题，一是 merge 的目标段数量不再倾向于 merge 为尽量少的段，例如目标段数量可以按照每个段 1GB 来计算，第二种是如果 cache 命中率不高，可以考虑降低 250 这个数字。https://www.easyice.cn/archives/386