translate by [williamzhao](https://github.com/williamzhao) ## 查詢與過濾 前面我們講到的是關于結構化查詢語句，事實上我們可以使用兩種結構化語句： 結構化查詢（Query DSL）和結構化過濾（Filter DSL）。 查詢與過濾語句非常相似，但是它們由于使用目的不同而稍有差異。 一條過濾語句會詢問每個文檔的字段值是否包含著特定值： * `created` 的日期范圍是否在 `2013` 到 `2014` ? * `status` 字段中是否包含單詞 "published" ? * `lat_lon` 字段中的地理位置與目標點相距是否不超過10km ? 一條查詢語句與過濾語句相似，但問法不同： 查詢語句會詢問每個文檔的字段值與特定值的匹配程度如何？ 查詢語句的典型用法是為了找到文檔： * 查找與 `full text search` 這個詞語最佳匹配的文檔 * 查找包含單詞 `run` ，但是也包含`runs`, `running`, `jog` 或 `sprint`的文檔 * 同時包含著 `quick`, `brown` 和 `fox` --- 單詞間離得越近，該文檔的相關性越高 * 標識著 `lucene`, `search` 或 `java` --- 標識詞越多，該文檔的相關性越高 一條查詢語句會計算每個文檔與查詢語句的相關性，會給出一個相關性評分 `_score`，并且 按照相關性對匹配到的文檔進行排序。 這種評分方式非常適用于一個沒有完全配置結果的全文本搜索。 ## 性能差異 使用過濾語句得到的結果集 -- 一個簡單的文檔列表，快速匹配運算并存入內存是十分方便的， 每個文檔僅需要1個字節。這些緩存的過濾結果集與后續請求的結合使用是非常高效的。 查詢語句不僅要查找相匹配的文檔，還需要計算每個文檔的相關性，所以一般來說查詢語句要比 過濾語句更耗時，并且查詢結果也不可緩存。 幸虧有了倒排索引，一個只匹配少量文檔的簡單查詢語句在百萬級文檔中的查詢效率會與一條經過緩存 的過濾語句旗鼓相當，甚至略占上風。 但是一般情況下，一條經過緩存的過濾查詢要遠勝一條查詢語句的執行效率。 過濾語句的目的就是縮小匹配的文檔結果集，所以需要仔細檢查過濾條件。 ## 什么情況下使用 原則上來說，使用查詢語句做全文本搜索或其他需要進行相關性評分的時候，剩下的全部用過濾語句