ES有两种格式的search api：
“lite”——query string版本，这个版本期望所有的参数在请求中指定并传递
full request body版本期望得到一个JSON请求体，并且使用一个名为DSL的丰富的搜索语言
query string搜索对在使用命令行的即席查询（ad
hoc queries）是很有用的。例如要查询type是tweet并且字段“tweet”包含"elasticsearch"单词的document：
GET /_all/tweet/_search?q=tweet:elasticsearch
下一个查询是从name字段中查出“john”和在tweet字段中查出“mary”：
+name:john +tweet:mary
查询字符串是需要对查询语句进行%编码的，经过编码的查询要比真是的查询语句看起来更隐秘：
GET /_search?q=%2Bname%3Ajohn+%2Btweet%3Amary
“+”前缀表示必须匹配要查询的条件。类似的“-”前缀必须不能匹配要查询的条件。没有“+”或“-”的都是可选项，越是匹配，搜索得到的document越是相关。
_all 字段
下面这个简单的查询返回了所有包含“mary”的document：
GET /_search?q=mary
以前的例子中，我们在tweet或这name字段中查询”mary“，然而这次，结果是从三个不同的field中得到的：
- a user whose name is "Mary"
- six tweets by "Mary"
- one tweet directed at "@mary"
ES是怎么从三个不同的字段中找到结果的呢？
当我们index一个document的时候，ES把每个field的值合并成一个大的字符串，这个大的字符串被放入到指定的_all字段中。例如，当我们index下面这个document：
{
"tweet": "However did I manage before Elasticsearch?",
"date": "2014-09-14",
"name": "Mary Jones",
"user_id": 1
}
这就好象我们另外添加了一个_all的field，其值是：
"However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1"
除非你在搜索的时候指定filed的名称，否则默认搜索的就是这个_all的field。
当你入门一个新的引用的时候，这个_all就是一个很有用的特点，如果你指定一个field而不是_all你就能对检索的结果获得更多的控制权。当你不再需要_all的时候，你可以让其失效，就像Metadata: _all field在介绍的一样。
更复杂的查询
下面的搜索查询是针对tweets的：
- where the
namefield contains"mary"or"john" - and where the
dateis greater than2014-09-10 - and which contain either of the words
"aggregations"or"geo"in the_allfield
+name:(mary john)+date:>2014-09-10+(aggregations geo)
编码后的查询语句如下：
?q=%2Bname%3A(mary+john)+%2Bdate%3A%3E2014-09-10+%2B(aggregations+geo)
从上面的案例中可以看出，简单的query
string功能强大的令人惊讶，他的语法在有详细的介绍，使我们能够简洁地表达比较复杂的查询。这使的ES非常适合在命令行或者开发过程中进行查询。
然而，你也看到了，这种简介也使他变得神秘和难以调试。并且，这个结构也是很脆弱的，一个简单的语法错误，比如-，：，/或者“
都将导致错误而无法返回结果。
最后，query string
允许任何用户对你的index的任何field进行潜在的慢重查询，这个会暴露你的私人信息，甚至将导致你的集群瘫痪。给予这个原因，不推荐直接query
string暴露给你的用户。
相反，在生产中，我们通常依赖于全功能的request body
这个搜索API，他能做上面所有的功能，但不仅仅这些。在我们学习这些之前，我们要先看一下我们的数据在ES中是怎么存储的。
原文:http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/search-lite.html
精简版搜索（search lite）,布布扣,bubuko.com