### 過濾順序 在 `bool` 條件中過濾器的順序對性能有很大的影響。更詳細的過濾條件應該被放置在其他過濾器之前，以便在更早的排除更多的文檔。 假如條件 A 匹配 1000 萬個文檔，而 B 只匹配 100 個文檔，那么需要將 B 放在 A 前面。 緩存的過濾器非常快，所以它們需要被放在不能緩存的過濾器之前。想象一下我們有一個索引包含了一個月的日志事件，然而，我們只對近一個小時的事件感興趣： ```json GET /logs/2014-01/_search { "query" : { "filtered" : { "filter" : { "range" : { "timestamp" : { "gt" : "now-1h" } } } } } } ``` 這個過濾條件沒有被緩存，因為它使用了 `now` 方法，這個值每毫秒都在變化。這意味著我們需要每次執行這條查詢時都檢測一整個月的日志事件。 我們可以通過組合一個緩存的過濾器來讓這變得更有效率：我們可以添加一個含固定時間的過濾器來排除掉這個月的大部分數據，例如昨晚凌晨： ```json "bool": { "must": [ { "range" : { "timestamp" : { "gt" : "now-1h/d" <1> } }}, { "range" : { "timestamp" : { "gt" : "now-1h" <2> } }} ] } ``` <1> 這個過濾器被緩存了，因為它使用了取整到昨夜凌晨 `now` 條件。 <2> 這個過濾器沒有被緩存，因為它沒有對 `now` 取整。 `now-1h/d` 條件取整到昨夜凌晨，所以所有今天之前的文檔都被排除掉了。這個結果的字節集被緩存了，因為 `now` 被取整了，意味著它只需要每天當_昨夜凌晨_的值改變時被執行一次。`now-1h` 條件沒有被緩存，因為 `now` 表示最近一毫秒的時間。然而，得益于第一個過濾器，第二個過濾器只需要檢測當天的文檔就行。 這些條件的排序很重要。上面的實現能正常工作是因為_自從昨晚凌晨_條件比_最近一小時_條件位置更前。假如它們用別的方式組合，那么_最近一小時_條件還是需要檢測所有的文檔，而不僅僅是昨夜以來的文檔。