?refresh

索引、更新、删除和批量API支持设置refresh，以控制何时由此请求做出的更改对搜索可见，这些是允许的值：

空字符串或true

• 在操作发生后立即刷新相关的主碎片和副本碎片（不是整个索引），以便更新后的文档立即出现在搜索结果中，只有经过仔细考虑和核实，从索引和搜索的角度来看，它不会导致性能低下之后，才能这样做。

wait_for

• 在应答之前，等待请求所做的更改被刷新可见，这并不是强制立即刷新，而是等待刷新发生。Elasticsearch会每index.refresh_interval（默认值为1秒）自动刷新已经更改的碎片，这个设置是动态的。调用Refresh API或在任何支持它的API上将refresh设置为true也会导致刷新，从而导致已经运行的带有refresh=wait_for的请求返回。

false（默认）

• 不执行刷新相关操作，此请求所做的更改将在请求返回后的某个时刻变得可见。

选择使用哪个设置

除非你有充分的理由等待更改变为可见，否则总是使用refresh=false，或者，因为这是默认值，所以将refresh参数排除在URL之外，这是最简单、最快的选择。

如果你必须使请求所做的更改可见与请求同步，那么你必须在对Elasticsearch增加更多负载（true）和等待更长时间的响应（wait_for）之间进行选择，以下几点应该为该决定提供参考：

• 与true相比，对索引进行的更改越多，wait_for节省越多的工作，在每次index.refresh_interval只更改一次索引的情况下，它不会节省任何工作。
• true创建的索引结构效率较低（小段），稍后必须合并为更高效的索引结构（大段），这意味着true的代价是在索引时创建小段，在搜索时搜索小段，在合并时制作大段。
• 不要在一行中启动多个refresh=wait_for请求，相反，将使用refresh=wait_for的请求批量到单个bulk请求中，Elasticsearch将会并行启动它们，只有当它们全部完成时才返回。
• 如果刷新间隔设置为-1，则禁用自动刷新，那么具有refresh=wait_for的请求将无限期地等待，直到某个操作导致刷新。相反，将index.refresh_interval设置为比默认值更短的值，比如200ms，将使refresh=wait_for返回的速度更快，但仍然会生成效率低下的段。
• refresh=wait_for只影响它所在的请求，但是，通过强制立即刷新，refresh=true将影响其他正在进行的请求，通常，如果你有一个正在运行的系统，你不希望打扰它，那么refresh=wait_for是一个较小的修改。

refresh=wait_for可以强制刷新

如果已经有index.max_refresh_listener（默认为1000）请求等待刷新的情况下在那个碎片上出现refresh=wait_for请求，那么该请求的行为就好像它已经将refresh设置为true一样：它将强制刷新。这保证了当refresh=wait_for请求返回时，它的更改对于搜索是可见的，同时防止对被阻塞的请求使用未检查的资源，如果一个请求因为耗尽了监听器插槽而强制刷新，那么它的响应将包含"forced_refresh": true。

Bulk请求在每个碎片上只占用一个插槽，不管它们修改碎片多少次。

样例

这将创建一个文档，并立即刷新索引，使其可见：

PUT /test/_doc/1?refresh
{"test": "test"}
PUT /test/_doc/2?refresh=true
{"test": "test"}

这将创建一个文档，而不需要做任何事情使其对于搜索可见：

PUT /test/_doc/3
{"test": "test"}
PUT /test/_doc/4?refresh=false
{"test": "test"}

这将创建一个文档，并等待它对于搜索成为可见：

PUT /test/_doc/4?refresh=wait_for
{"test": "test"}