## 簡易搜索 `search` API有兩種表單：一種是“簡易版”的**查詢字符串(query string)**將所有參數通過查詢字符串定義，另一種版本使用JSON完整的表示**請求體(request body)**，這種富搜索語言叫做結構化查詢語句（DSL） 查詢字符串搜索對于在命令行下運行**點對點(ad hoc)**查詢特別有用。例如這個語句查詢所有類型為`tweet`并在`tweet`字段中包含`elasticsearch`字符的文檔： ```javascript GET /_all/tweet/_search?q=tweet:elasticsearch ``` 下一個語句查找`name`字段中包含`"john"`和`tweet`字段包含`"mary"`的結果。實際的查詢只需要： +name:john +tweet:mary 但是**百分比編碼(percent encoding)**（譯者注：就是url編碼）需要將查詢字符串參數變得更加神秘： ```Javascript GET /_search?q=%2Bname%3Ajohn+%2Btweet%3Amary ``` `"+"`前綴表示語句匹配條件**必須**被滿足。類似的`"-"`前綴表示條件**必須不**被滿足。所有條件如果沒有`+`或`-`表示是可選的——匹配越多，相關的文檔就越多。 ### `_all`字段 返回包含`"mary"`字符的所有文檔的簡單搜索： ```javascript GET /_search?q=mary ``` 在前一個例子中，我們搜索`tweet`或`name`字段中包含某個字符的結果。然而，這個語句返回的結果在三個不同的字段中包含`"mary"`： * 用戶的名字是“Mary” * “Mary”發的六個推文 * 針對“@mary”的一個推文 Elasticsearch是如何設法找到三個不同字段的結果的？ 當你索引一個文檔，Elasticsearch把所有字符串字段值連接起來放在一個大字符串中，它被索引為一個特殊的字段`_all`。例如，當索引這個文檔： ```javascript { "tweet": "However did I manage before Elasticsearch?", "date": "2014-09-14", "name": "Mary Jones", "user_id": 1 } ``` 這好比我們增加了一個叫做`_all`的額外字段值： ```javascript "However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1" ``` 若沒有指定字段，查詢字符串搜索（即q=xxx）使用`_all`字段搜索。 > ### TIP > `_all`字段對于開始一個新應用時是一個有用的特性。之后，如果你定義字段來代替`_all`字段，你的搜索結果將更加可控。當`_all`字段不再使用，你可以停用它，這個會在《全字段》章節闡述。 ### 更復雜的語句 下一個搜索推特的語句： `_all` field * `name`字段包含`"mary"`或`"john"` * `date`晚于`2014-09-10` * `_all`字段包含`"aggregations"`或`"geo"` ```javascript +name:(mary john) +date:>2014-09-10 +(aggregations geo) ``` 編碼后的查詢字符串變得不太容易閱讀： ```javascript ?q=%2Bname%3A(mary+john)+%2Bdate%3A%3E2014-09-10+%2B(aggregations+geo) ``` 就像你上面看到的例子，**簡單(lite)**查詢字符串搜索驚人的強大。它的查詢語法，會在《查詢字符串語法》章節闡述。參考文檔允許我們簡潔明快的表示復雜的查詢。這對于命令行下一次性查詢或者開發模式下非常有用。 然而，你可以看到簡潔帶來了隱晦和調試困難。而且它很脆弱——查詢字符串中一個細小的語法錯誤，像`-`、`:`、`/`或`"`錯位就會導致返回錯誤而不是結果。 最后，查詢字符串搜索允許任意用戶在索引中任何一個字段上運行潛在的慢查詢語句，可能暴露私有信息甚至使你的集群癱瘓。 > ### TIP > 因為這些原因，我們不建議直接暴露查詢字符串搜索給用戶，除非這些用戶對于你的數據和集群可信。 取而代之的，生產環境我們一般依賴全功能的**請求體**搜索API，它能完成前面所有的事情，甚至更多。在了解它們之前，我們首先需要看看數據是如何在Elasticsearch中被索引的。