?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"}