?refresh （冲刷）

Index、Update、Delete和BulkAPI支持设置refresh以控制此请求所做的更改对搜索可见。这些是允许的值：

空字符串或true

  在操作发生后立即刷新相关的主要和副本分片（不是整个索引），以便更新的文档立即显示在搜索结果中。只有仔细思考和验证才能从索引和搜索的角度出发，不会导致性能不佳。

wait_for

  等待请求所做的更改在返回之前通过冲刷显示。这不会强制立即刷新，而是等待刷新发生。 Elasticsearch会自动每隔index.refresh_interval刷新已经更改的分片，默认为1秒。该设置是动态的。调用Refresh API或将任何支持该API的refresh设置为true也将导致刷新，从而导致已经运行的请求与refresh=wait_for返回。

假（默认）

  不要刷新相关的动作。在请求返回后，此请求所做的更改将在某个时刻显示。

选择哪个设置来使用

除非你有一个很好的理由等待修改变得可见，总是使用refresh=false，或者，因为这是默认值，只需将刷新参数退出URL。那是最简单和最快的选择。

如果你一定要让所做的修改请求同步可见，那么您必须在对Elasticsearch（true）进行更多的负载与更长的等待响应（wait_for）之间进行选择。这里有几点应该告诉这个决定：

• 与设置为true相比，wait_for能让索引做更多的变更工作，在这种情况下，每隔index.refresh_interval索引的修改只才会保存。
• true将构造较小的有效的索引（微小段），以后必须将其合并到更有效的索引构造（较大的段）中。这意味着设置为true时，索引将花费时间在创建微小段上面，在搜索时从微小段进行搜索，并在合并时来制作较大段。
• 不要在一行中启动多个refresh=wait_for请求。而是通过一个Bulk请求来使用refresh=wait_for，Elasticsearch将并行执行它们，并且只有当它们全部完成时才返回。
• 如果刷新间隔设置为-1，则禁用了自动刷新，则refresh=wait_for的请求将无限期地等待，直到某些其它操作导致刷新。相反，将index.refresh_interval设置为小于默认值譬如200ms，refresh=wait_for更快地恢复，但仍会生成低效的段。
• refresh=wait_for仅影响其所在的请求，但是，通过强制立即刷新，refresh=true将影响其他正在进行的请求。一般来说，如果你有一个运行的系统，你不想打扰，那么refresh=wait_for是一个较小的修改。

refresh=wait_for能强制刷新

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

Bulk请求只占用接触的每个分片上的一个slot，无论他们修改分片多少次。

示例

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

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

这些将创建一个文档，而不做任何使其可以搜索的事情：

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

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

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