汤不热吧Elasticsearch（基于Lucene）在数据写入时，并不会立即修改大文件，而是不断创建小的、不可变的索引文件，这些文件被称为“段”（Segment）。段数量过多是影响Elasticsearch性能的常见瓶颈：过多的段会占用更多的文件句柄、消耗更多的JVM堆内存来维护元数据，并降低查询效率。
虽然Elasticsearch的TieredMergePolicy会自动进行后台合并，但在某些特定场景下（例如索引完成大批量写入后，或者索引被设置为只读状态时），我们可以手动强制合并段，将其数量减少到最小（通常是1），从而最大化索引的存储效率和查询速度。
一、强制合并的原理与适用场景
_forcemerge API允许用户手动触发段合并过程。当我们将索引用于归档或不再进行频繁写入时，执行强制合并能带来显著优势：
- 降低资源消耗： 段数减少，系统需要维护的Segment元数据更少，降低了堆内存使用。
- 提升查询性能： 检索时需要访问的文件减少，Lucene可以更快地定位和遍历数据。
- 释放存储空间： 删除标记（deleted documents）会在合并时被清除，有效回收磁盘空间。
二、实操步骤：使用 _forcemerge 进行优化
我们以索引 my_archive_index 为例，演示如何进行高效的强制合并。
步骤 1：检查当前的段数量 (可选)
在操作之前，先查看索引当前的段信息，了解优化的空间。
GET /my_archive_index/_segments
步骤 2：临时禁用索引副本
强制合并是一个IO密集型操作。如果在主分片合并后，ES必须将合并后的段数据同步给所有副本，会产生额外的IO和网络负担。因此，在合并过程中，通常推荐临时将索引的副本数量设置为0。
# 临时设置副本数为0
PUT /my_archive_index/_settings
{
"settings": {
"index.number_of_replicas": 0
}
}
步骤 3：执行强制合并
使用 _forcemerge API，并指定关键参数 max_num_segments=1。这将指示Elasticsearch将索引中的所有段（包括所有分片）合并成每个分片一个段。
注意： 强制合并是阻塞操作，且资源消耗大，应在系统低峰期执行。
# 执行强制合并，将每个分片合并为最多1个段，并执行一次刷新(flush)
POST /my_archive_index/_forcemerge?max_num_segments=1&flush=true
执行成功后，API会返回 { “_shards”: { … } } 结构，表示合并任务已完成。
步骤 4：恢复索引副本设置
合并完成后，恢复索引的副本数量。Elasticsearch会利用合并后的新段重新构建副本。
# 恢复副本数为1
PUT /my_archive_index/_settings
{
"settings": {
"index.number_of_replicas": 1
}
}
三、注意事项
- 勿在写入频繁的索引上使用： 对于有大量写入和更新操作的索引，不建议手动强制合并。自动合并策略（TieredMergePolicy）会更有效地处理不断变化的数据。
- IO消耗高： 强制合并是一个重度IO操作，可能会暂时影响集群的响应速度。
- 空间效率： 强制合并不仅能减少段数，还能彻底清除已删除文档的残留空间，是回收磁盘空间的有效手段。