Lucene的段机制：为什么索引会变成一堆碎片？
Elasticsearch底层的倒排索引是基于Lucene构建的，而Lucene为了提高写入吞吐量，采用了一种追加写入、不可变分片的策略。每当有新的文档写入，或者发生更新、删除操作时，Lucene不会直接修改原有的索引数据，而是将它们写入一个个新的段（Segment）中。每个段都有自己独立的倒排表、词向量、doc values等结构，相当于一个微型只读索引。
这种设计的最大好处是写入极快，因为数据只需要顺序追加到磁盘，无须加锁修改已有文件。但随着时间推移，索引中会堆积大量的小段。比如你每次批量写入几千条文档，可能就会产生一个新段，一天下来几百个段的情况并不少见。查询操作需要遍历所有段，对CPU和文件句柄的消耗会显著上升，尤其是那些读多写少的场景，查询延迟会随着段数量的增加而恶化。
Lucene本身提供了自动合并策略（TieredMergePolicy），后台会按照一定的规则把这些小段合并成大段，从而控制段的数量。但这个自动合并是有上限的，它不会把所有段合并成一个，而是尽量维持在合理水平，保证写入和查询的平衡。而forcemerge就是由用户主动发起、跳过部分策略约束、将索引合并到指定最大段数量的操作，通常用在只读索引或不再有大量写入的场景中。
forcemerge API的使用方法和关键参数
在Elasticsearch里，forcemerge命令通过_forcemerge API执行。最简单的形式就是直接对指定索引发出请求，不填任何参数时，默认会将索引的所有分片合并到1个段。这个行为对一些小索引可能没什么感觉，但对几百GB的大分片来说，会引发极其剧烈的I/O操作，因此绝对不能在业务高峰期随便裸调用。
POST /my_index/_forcemerge
更推荐的做法是结合参数进行控制。第一个关键参数是max_num_segments，它指定了每个分片最终期望保留的最大段数量。如果把值设为1，Elasticsearch会努力把所有小段合并成一个大段，但过程中需要大量的临时磁盘空间和内存。通常对于不再有写入的索引，设为1是合理的；如果还有少量写入，可以设为5或者10，给后续小段留下合并余地，避免造成大量写负载。
POST /my_index/_forcemerge?max_num_segments=1
第二个常用参数是only_expunge_deletes。当文档被删除或更新时，旧版本文档并不会立刻从段中被物理清除，而是标记为已删除，等待后续合并时才会真正移除。执行带only_expunge_deletes=true的forcemerge，相当于告诉Elasticsearch：只合并那些包含大量已删除文档的段，把它们清理掉，而不追求把段数量降到某个固定值。这个操作对磁盘空间的回收效果很明显，而且对I/O的压力比完全合并到1个段要小得多。
POST /my_index/_forcemerge?only_expunge_deletes=true
此外，还可以通过flush参数控制合并前是否需要先执行一次flush，确保事务日志数据落盘；requests_per_second在7.x版本之前也存在，用来限制合并速率，但新版中已废弃，转为通过索引设置控制合并I/O节流。
forcemerge到底会带来什么代价？
段合并是一个非常消耗资源的操作，它的本质是读取多个小段的数据，在内存中进行归并排序，再写入新的大段，最后删除旧段。在这个过程中，磁盘I/O会达到峰值，物理CPU使用率也会急剧上升。如果你在一个正在处理读请求的节点上执行forcemerge，查询延迟可能会出现数倍甚至数十倍的抖动，这在大促或高频访问场景下是不可接受的。
另一个被忽视的问题是磁盘临时空间。假设一个分片原本占用50GB，执行合并到1个段时，新旧段会同时存在一段时间，需要的额外空间可能等于甚至大于原数据量。如果节点磁盘利用率已经很高，合并中途磁盘被打满会导致整个节点写阻塞，分片状态变红。因此，执行前务必确保每个数据节点至少有索引大小30%以上的剩余空间，合并的目标分片越大，余量应该越充足。
合并过大的段还会影响集群恢复速度。一个100GB的分片如果被合并成单个大段，当发生节点迁移、故障恢复时，需要整个分片文件完整传输，无法利用差量复制，快照恢复的灵活性也会下降。所以对于仍然可能发生扩缩容的热索引，并不建议将段合并到极限值。
什么场景真正需要手动forcemerge？
最经典的适用场景是日志类、时序类只读索引。比如按天滚动的应用日志索引，当一天结束后不再有新数据写入，此时就可以执行一次forcemerge，将每个分片合并到很少的段甚至1个段。这样后续的查询、聚合、排序性能都会有明显提升，因为需要扫描的段文件和打开的FD句柄大幅减少。执行完毕后建议紧接着调用一次_cache/clear清理各节点上的查询缓存，否则旧缓存仍会引用已被删除的段，浪费内存。
还有一种情况是磁盘空间紧急回收。当索引经历了大量删除操作，磁盘空间居高不下，而自动合并又因为写入压力或策略限制没有及时收缩，就可以使用only_expunge_deletes来强制清理已删除文档占用的空间。这一点在写入频繁且删除率高的消息队列类索引里很实用。
如果你需要为某个索引生成离线快照或做冷数据归档，事先执行一次forcemerge也有好处。合并后段数量减少，快照生成的元数据会更轻量，恢复时也能减少段文件的数量。但要注意最好在非高峰时段，或者将索引暂时设置为只读后再操作。
需要谨慎对待的情况则包括：还有持续写入的在线业务索引、数据节点磁盘已经接近警戒线、集群内正有大批量rebalance或分片恢复任务在执行。这些场景下盲目调用forcemerge很可能导致集群雪崩。一个折中方案是把操作粒度拆到单分片，通过_cat/shards观察各分片的segment count，对段数特别高的分片逐个处理，并适当提高索引的合并策略阈值，让后续写入不会立即又产生大量新段。
监控合并过程与效果验证
在执行forcemerge之前和之后，都应该通过监控来评估效果。Elasticsearch提供了_cat/segments API，可以查看每个索引每个分片的段数量、大小、是否包含已删除文档等信息。例如：
GET /_cat/segments/my_index?v&h=index,shard,segment,size,committed,searchable,generation,deleted_docs
执行前记录下分片的segment数量和总体大小，执行完后对比变化。如果发现某些分片并没有被合并到预期数量，可能是它们已经满足max_num_segments要求，或者当前合并线程池被其他任务占用。可以通过_nodes/hot_threads查看merge线程是否在忙，结合_cat/thread_pool/force_merge?v观察队列积压情况。
值得关注的一个指标是段合并导致的查询延迟波动。可以通过索引级别的statistics接口观察search query time的变化，如果合并期间latency出现尖峰，说明I/O争抢严重，下次可以考虑通过indices.store.throttle.type等设置限制合并对查询的影响，或者干脆临时关闭自动刷新来预留更多IO能力。
Elasticsearchforcemerge段合并修改时间：2026-08-12 07:54:58