调大 refresh_interval 能显著提升写入吞吐，因为减少高频 refresh 可降低小 segment 生成频率，从而减轻后台 segment merge 的 CPU 和 I/O 压力，避免 merge 线程抢占 bulk 处理资源。
为什么调大 refresh_interval 能显著提升写入吞吐
每次 refresh 都会把内存中的 indexing buffer 生成一个新 segment，哪怕只是几 MB 的小段。这些小段会立刻参与后续查询，但更关键的是——它们会触发后台频繁的 segment merge。而 merge 是 CPU + I/O 双重密集型操作，尤其在高写入场景下，merge 线程会被持续抢占，反过来拖慢 bulk 处理速度。调大 refresh_interval 不是“让数据变慢”，而是把 refresh 从高频毛刺行为变成低频批量动作，从而降低整体系统抖动。
怎么安全地调大 refresh_interval
它是个索引级设置，必须在索引创建后、写入前或写入中动态调整。注意：修改只影响后续写入，已存在的 segment 不会回滚刷新节奏。
- 临时关闭自动刷新（适合批量灌库）：
PUT /my_index/_settings { "index.refresh_interval": "-1" }，之后需手动调用POST /my_index/_refresh才能查到新数据 - 设为 30 秒（平衡实时性与吞吐）：
PUT /my_index/_settings { "index.refresh_interval": "30s" } - 设为 120 秒（日志类场景常用）：
PUT /my_index/_settings { "index.refresh_interval": "120s" } - 不能设为 0 或小于 100ms；
-1表示禁用，不是“立即刷新”
容易踩的坑：refresh 和 translog、flush 不是一回事
新手常混淆这三个概念：
-
refresh_interval控制的是“可搜索性”，不影响数据可靠性 —— 即使设为-1，只要 translog 没丢，重启后数据仍能恢复 -
index.translog.durability才决定写入是否落盘（requestvsasync），这才是影响丢失风险的关键 -
index.translog.sync_interval控制 translog 刷盘频率，和 refresh 完全正交；两者可以同时调大，但必须分清各自职责 - 如果业务依赖“写完立刻能搜”，比如订单状态变更页，就别盲目调大 —— 先确认真实 SLA，再决定是否接受 1~30 秒延迟
配合 refresh_interval 必须同步检查的点
单改这个参数效果有限，它真正起效的前提是其他链路不卡住：
- 确保
index.translog.durability不是request（否则每次写都要刷盘，refresh 再慢也白搭） - bulk 请求体大小建议控制在 5MB~10MB，避免单次请求过大导致协调节点 OOM 或超时
- 写入期间副本数可临时设为 0：
PUT /my_index/_settings { "number_of_replicas": 0 }，导入完成再改回，省去副本同步开销 - 观察
_nodes/stats/indices?filter_path=**.refresh*，确认total增速明显下降，且pending不持续堆积
