# ?refresh （沖刷） [Index](Index_API.md)、[Update](Update_API.md)、[Delete](Delete_API.md)和[Bulk](Bulk_API.md)API支持設置`refresh`以控制此請求所做的更改對搜索可見。這些是允許的值： 空字符串或`true` 在操作發生后立即刷新相關的主要和副本分片（不是整個索引），以便更新的文檔立即顯示在搜索結果中。只有仔細思考和驗證才能從索引和搜索的角度出發，不會導致性能不佳。 `wait_for` 等待請求所做的更改在返回之前通過沖刷顯示。這不會強制立即刷新，而是等待刷新發生。 Elasticsearch會自動每隔`index.refresh_interval`刷新已經更改的分片，默認為`1`秒。該設置是[動態](../Index_Modules.md#dynamic-index-settings)的。調用[Refresh](../Indices_APIs/Refresh.md) 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"} ```