### 關于緩存 在【內部過濾操作】章節中，我們簡單提到過過濾器是怎么計算的。它們的核心是一個字節集來表示哪些文檔符合這個過濾器。Elasticsearch 主動緩存了這些字節集留作以后使用。一旦緩存后，當遇到相同的過濾時，這些字節集就可以被重用，而不需要重新運算整個過濾。 緩存的字節集很“聰明”：他們會增量更新。你索引中添加了新的文檔，只有這些新文檔需要被添加到已存的字節集中，而不是一遍遍重新計算整個緩存的過濾器。過濾器和整個系統的其他部分一樣是實時的，你不需要關心緩存的過期時間。 #### 獨立的過濾緩存 每個過濾器都被獨立計算和緩存，而不管它們在哪里使用。如果兩個不同的查詢使用相同的過濾器，則會使用相同的字節集。同樣，如果一個查詢在多處使用同樣的過濾器，只有一個字節集會被計算和重用。 讓我們看一下示例，查找符合下列條件的郵箱： * 在收件箱而且沒有被讀取過 * _不在_收件箱但是被標記為重要 ```json "bool": { "should": [ { "bool": { "must": [ { "term": { "folder": "inbox" }}, <1> { "term": { "read": false }} ] }}, { "bool": { "must_not": { "term": { "folder": "inbox" } <1> }, "must": { "term": { "important": true } } }} ] } ``` <1> 這兩個過濾器相同，而且會使用同一個字節集。 雖然一個收件箱條件是 `must` 而另一個是 `must_not`，這兩個條件本身是相等的。這意味著字節集會在第一個條件執行時計算一次，然后作為緩存被另一個條件使用。而第二次執行這條查詢時，收件箱的過濾已經被緩存了，所以兩個條件都能使用緩存的字節集。 這與查詢 DSL 的組合型緊密相關。移動過濾器或在相同查詢中多處重用相同的過濾器非常簡單。這不僅僅是方便了開發者 —— 對于性能也有很大的提升 #### 控制緩存 大部分直接處理字段的_枝葉過濾器_（例如 `term`）會被緩存，而像 `bool` 這類的組合過濾器則不會被緩存。 【提示】 枝葉過濾器需要在硬盤中檢索倒排索引，所以緩存它們是有意義的。另一方面來說，組合過濾器使用快捷的字節邏輯來組合它們內部條件生成的字節集結果，所以每次重新計算它們也是很高效的。 然而，有部分枝葉過濾器，默認不會被緩存，因為它們這樣做沒有意義： 腳本過濾器： 腳本過濾器的結果不能被緩存因為腳本的意義對于 Elasticsearch 來說是不透明的。 Geo 過濾器： 定位過濾器（我們會在【geoloc】中更詳細的介紹），通常被用于過濾基于特定用戶地理位置的結果。因為每個用戶都有一個唯一的定位，geo 過濾器看起來不太會重用，所以緩存它們沒有意義。 日期范圍： 使用 `now` 方法的日期范圍（例如 `"now-1h"`），結果值精確到毫秒。每次這個過濾器執行時，`now` 返回一個新的值。老的過濾器將不再被使用，所以默認緩存是被禁用的。然而，當 `now` 被取整時（例如，`now/d` 取最近一天），緩存默認是被啟用的。 有時候默認的緩存測試并不正確。可能你希望一個復雜的 `bool` 表達式可以在相同的查詢中重復使用，或你想要禁用一個 `date` 字段的過濾器緩存。你可以通過 `_cache` 標記來覆蓋幾乎所有過濾器的默認緩存策略 ```json { "range" : { "timestamp" : { "gt" : "2014-01-02 16:15:14" <1> }, "_cache": false <2> } } ``` <1> 看起來我們不會再使用這個精確時間戳 <2> 在這個過濾器上禁用緩存 以后的章節將提供一些例子來說明哪些時候覆蓋默認緩存策略是有意義的。