#合并段 通過每秒自動刷新創建新的段，用不了多久段的數量就爆炸了。有太多的段是一個問題。每個段消費文件句柄，內存，cpu資源。更重要的是，每次搜索請求都需要依次檢查每個段。段越多，查詢越慢。 ES通過后臺合并段解決這個問題。小段被合并成大段，再合并成更大的段。 這是舊的文檔從文件系統刪除的時候。舊的段不會再復制到更大的新段中。 這個過程你不必做什么。當你在索引和搜索時ES會自動處理。這個過程如圖：兩個提交的段和一個未提交的段合并為了一個更大的段所示： 1. 索引過程中，refresh會創建新的段，并打開它。 2. 合并過程會在后臺選擇一些小的段合并成大的段，這個過程不會中斷索引和搜索。 **圖1：兩個提交的段和一個未提交的段合并為了一個更大的段**  3. 下圖描述了合并后的操作： * 新的段flush到了硬盤。 * 新的提交點寫入新的段，排除舊的段。 * 新的段打開供搜索。 * 舊的段被刪除。 **圖2：段合并完后，舊的段被刪除**  合并大的段會消耗很多IO和CPU，如果不檢查會影響到搜素性能。默認情況下，ES會限制合并過程，這樣搜索就可以有足夠的資源進行。 ##optimize API `optimize API`最好描述為強制合并段API。它強制分片合并段以達到指定`max_num_segments`參數。這是為了減少段的數量（通常為1）達到提高搜索性能的目的。 >警告 >不要在動態的索引（正在活躍更新）上使用`optimize API`。后臺的合并處理已經做的很好了，優化命令會阻礙它的工作。不要干涉！ 在特定的環境下，`optimize API`是有用的。典型的場景是記錄日志，這中情況下日志是按照每天，周，月存入索引。舊的索引一般是只可讀的，它們是不可能修改的。 這種情況下，把每個索引的段降至1是有效的。搜索過程就會用到更少的資源，性能更好: ```Javascript POST /logstash-2014-10/_optimize?max_num_segments=1 <1> ``` - &lt;1> 把索引中的每個分片都合并成一個段