refresh=true、refresh=wait_for 与默认刷新

做的事：真实把索引的refresh_interval设成5秒，分别测试默认、refresh=true、refresh=wait_for三种写入方式

代码PUT /ref_test {"settings":{"refresh_interval":"5s"}} 默认: POST /ref_test/_doc/1 {"n":1} refresh=true: POST /ref_test/_doc/2?refresh=true {"n":2} refresh=wait_for: POST /ref_test/_doc/3?refresh=wait_for {"n":3}

验证：默认写入后立刻搜索真实0命中，必须等下一次自然的5秒刷新周期

实测 · 本机 Elasticsearch 8.15.0 执行输出

默认写入后立刻搜索: hits=0   ← 真实查不到刚写入的文档

这个真实结果是本系列反复提到的"ES是近实时搜索"的直接体现：写入操作本身真实很快就返回了，但文档真实要等到下一次refresh把内存里的数据刷成可搜索的Lucene段之后才能被搜到，默认情况下这个刷新真实按refresh_interval的节奏自然发生，不会因为某一次写入而提前触发。

验证：refresh=true的写入调用真实只多花了0.015秒，返回后立刻搜索真实就命中了

实测 · 本机执行输出

refresh=true写入调用耗时: 0.015秒
写入调用返回后立刻搜索: hits=1   ← 真实立刻就能搜到

这组结果验证了refresh=true真实的工作方式：它真实会在这次写入完成之后，立刻强制插入一次额外的、不在原本5秒节奏里的刷新，确保这次写入的内容真实能被立刻搜到。真实只多花了0.015秒，因为触发一次刷新本身（把内存缓冲区的数据写成一个新的Lucene段）真实是一个相对轻量的操作，不需要等到下一个自然周期。

真实验证refresh=wait_for：这次写入调用本身会卡住等多久才返回

代码POST /ref_test/_doc/3?refresh=wait_for {"n":3}

验证：refresh=wait_for的写入调用真实卡住等了4.285秒才返回，比refresh=true慢了近300倍

实测 · 本机执行输出

refresh=wait_for写入调用耗时: 4.285秒   ← 真实比refresh=true的0.015秒慢了近300倍
调用返回后立刻搜索: hits=1   ← 真实同样能搜到

这组真实结果精确揭示了refresh=wait_for跟refresh=true之间看似相似（两者最终都能让调用方确信写入的文档已经可搜索）、但真实机制完全不同的关键区别：refresh=true真实是"立刻强行插入一次额外的刷新"，而refresh=wait_for真实是"不强行插入任何额外刷新，只是让这次写入请求本身阻塞住，等到下一次反正本来就会自然发生的刷新周期真正完成之后再返回"——本次实测这篇文档真实恰好写在本次5秒周期的早期阶段，所以真实要等将近4.3秒才等到下一次自然刷新完成。refresh=wait_for的真实价值在于：它真实不会像refresh=true那样每次写入都额外插入一次刷新（如果写入频率很高，refresh=true真实会导致刷新频率远超refresh_interval设定的节奏，产生大量小的Lucene段拖累真实的查询性能和合并开销），而是真实复用了集群本来的刷新节奏，用增加写入请求本身的响应延迟为代价，换取不扰乱既有的刷新频率——这是一个真实在"写入立刻可见"和"不破坏刷新节奏"之间做权衡的中间档位选择。

分步演示：默认、refresh=true、refresh=wait_for三种刷新策略的真实机制差异完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。

refresh=true强行插入额外刷新，refresh=wait_for只是阻塞等待自然刷新完成

这一步新验证的refresh模式

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 refresh 写入参数与 refresh_interval 设置

下一篇 · ELASTICSEARCH 95

Refresh、Flush、Commit 的区别