forcemerge仅对open状态索引生效，冻结或关闭索引会报错；执行前需确认索引未冻结、未设只读块，并依据段数、删除率和段大小判断是否适合合并，生产环境须加安全参数与异步控制。
只读索引执行 forcemerge 前必须先确认状态
forcemerge 只对 open 状态的索引生效，frozen 或 closed 索引会直接报错 illegal_argument_exception。很多用户卡在这一步——以为“只读”就等于“可 merge”，其实冻结（freeze）后的索引连段信息都不可见，更别说合并了。
验证方式很简单：
- 查索引状态：
curl -s 'http://localhost:9200/my-index-2025-01-01/_cat/indices?v&h=index,status,health'，确保 status 是open - 确认未冻结：
curl -s 'http://localhost:9200/my-index-2025-01-01/_settings?filter_path=**.frozen'，返回空或"frozen":false才行 - 检查是否被设为只读块：
curl -s 'http://localhost:9200/_cluster/settings?include_defaults=false'，避免blocks.read_only_allow_delete干扰
forcemerge 的关键参数与安全阈值
直接跑 _forcemerge?max_num_segments=1 很危险：它会强制把所有 segment 合成一个，IO 和 CPU 尖峰可能拖垮节点，尤其在业务高峰期。生产环境必须加约束：
-
max_num_segments=1仅适用于已停止写入、段数 ≥ 10 的只读索引；段数少于 5 时没必要强合 - 务必加上
only_expunge_deletes=true—— 这个参数会物理清理 .del 文件中标记删除的文档，真正释放磁盘空间 - 用
wait_for_completion=false异步提交，再轮询_tasks查进度，避免请求超时中断 - 限制并发：通过
merge.policy.max_merge_at_once（索引级设置）或集群级indices.memory.index_buffer_size控制资源占用
示例命令：
curl -XPOST 'http://localhost:9200/my-index-2025-01-01/_forcemerge?max_num_segments=1&only_expunge_deletes=true&wait_for_completion=false'
如何判断一个索引“适合” forcemerge
不是所有只读索引都值得 merge。重点看三个指标，用 _cat/segs 查：
- 段数量（
segments列）＞ 15，且平均段大小 ＜ 5GB → 合并收益明显 -
deletes列数值高（比如 > 5% 总文档数），说明逻辑删除多，only_expunge_deletes=true能释放空间 -
size列显示大量小段（如几百 MB），而size.memory占用高 → 段太多吃内存，合并后能降 JVM 压力
反例：一个只有 3 个段、总大小 80GB 的索引，强行 max_num_segments=1 不仅没收益，还触发大 IO，得不偿失。
定期自动化要绕开两个坑
用 cron 脚本定时跑 forcemerge 很常见，但容易踩两个隐形雷：
- ES 默认禁止并发 merge 同一索引：如果上一次任务还没结束，下次 cron 触发会失败，日志里是
task_already_exists_exception。需在脚本里加锁检查_tasks?detailed=true&q=action:indices:admin/forcemerge - merge 过程中若节点重启或断电，残留的临时段文件不会自动清理，下次 merge 会跳过这些“脏段”。建议每次 merge 前先做
_flush，确保 translog 清空 - 别把所有历史索引塞进一个定时任务：按数据时间分批，比如每月合并上月索引，避免某次失败导致全量积压
真正省心的做法是结合 ILM：在 warm 阶段配 forcemerge 动作 + shrink，由 ES 自动调度，比脚本更稳。
_cat/recovery 确认集群无其他恢复任务，再动手。
