Refresh
Index,Update,Delete和Bulk APIs支持设置刷新以控制由该请求做出的更改在搜索时可见。
这些是允许的值：
- 空字符串或true：在操作发生后立即刷新相关的主分片和副本分片（而不是整个索引），以便更新的文档立即显示在搜索结果中。只有在从索引和搜索角度进行仔细考虑并验证它不会导致性能不佳之后，才能进行此操作。
- wait_for：在答复之前，等待由请求所做的更改以刷新进行可见。这不会强制立即刷新，而是等待刷新发生。Elasticsearch会自动刷新每个index.refresh_interval默认为1s的分片。这种设置是动态的。在支持它的任何API上调用刷新API或将刷新设置为true也会导致刷新，进而导致已经运行的请求refresh=wait_for返回。
- false（默认）：不采取与刷新相关的操作。此请求所做的更改将在请求返回后的某个时间点显示。
选择使用哪个设置
除非你有一个很好的理由等待更改变为可见，否则使用refresh=false，或者，因为这是默认的，只需将刷新参数从URL中删除。这是最简单快捷的选择。
如果必须让请求所做的更改与请求同步可见，则需在Elasticsearch（true）上放置更多的负载和等待更长时间的响应（wait_for）之间做出选择。这里有几个要点要告诉我们的：
对索引所做的更改越多，工作节省的工作量就越多。如果索引每次只更改一次，index.refresh_interval则不会保存任何工作。
创建效率较低的索引构造（小段），这些构造稍后必须合并为更有效的索引构造（更大的段）。这意味着真实的成本是在索引时间内创建的，在搜索时间搜索微小的片段，并在合并时创建更大的段。
永远不要用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。
批量请求只在每个分片上占用一个槽，无论他们修改分片多少次。
e.g.
创建一个文档并立即刷新索引，使其可见：
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"
}