空搜索：
GET /_search
hits：
- total 總數
- hits 前10條數據
- hits 數組中的每個結果都包含_index、_type和文檔的_id字段，被加入到_source字段中這意味着在搜索結果中我們將可以直接使用全部文檔。
- 每個節點都有一個_score字段，這是相關性得分(relevance score)，它衡量了文檔與查詢的匹配程度。默認的，返回的結果中關聯性最大的文檔排在首位；這意味着，它是按照_score降序排列的。沒有指定任何查詢，所以所有文檔的相關性是一樣的，因此所有結果的_score都是取得一個中間值1。
took：整個搜索請求花費的毫秒數。
_shards：節點告訴我們參與查詢的分片數（total字段），有多少是成功的（successful字段），有多少的是失敗的（failed字段）。
time_out：告訴我們查詢超時與否。一般的，搜索請求不會超時。如果響應速度比完整的結果更重要，你可以定義timeout參數為10或者10ms（10毫秒），或者1s（1秒）
GET /_search?timeout=10ms
Elasticsearch將返回在請求超時前收集到的結果。
注意：timeout不會停止執行查詢，它僅僅告訴你目前順利返回結果的節點然后關閉連接。在后台，其他分片可能依舊執行查詢，盡管結果已經被發送。
使用超時是因為對於你的業務需求來說非常重要，而不是因為你想中斷執行長時間運行的查詢。
多索引和多類別
在所有索引的所有類型中搜索：/_search
在索引gb的所有類型中搜索：/gb/_search
在索引gb和us的所有類型中搜索：/gb,us/_search
在以g或u開頭的索引的所有類型中搜索：/g*,u*/_search
在索引gb的類型user中搜索：/gb/user/_search
在索引gb和us的類型為user和tweet中搜索：/gb,us/user,tweet/_search
在所有索引的user和tweet中搜索：/_all/user,tweet/_search
當你搜索包含單一索引時，Elasticsearch轉發搜索請求到這個索引的主分片或每個分片的復制分片上，然后聚集每個分片的結果。搜索包含多個索引也是同樣的方式——只不過會有更多的分片被關聯。
分頁
如果你想每頁顯示5個結果，頁碼從1到3，那請求如下：
GET /_search?size=5
GET /_search?size=5&from=5
GET /_search?size=5&from=10
應該當心分頁太深或者一次請求太多的結果。結果在返回前會被排序。但是記住一個搜索請求常常涉及多個分片。每個分片生成自己排好序的結果，它們接着需要集中起來排序以確保整體排序正確。
現在假設我們請求第1000頁——結果10001到10010。工作方式都相同，不同的是每個分片都必須產生頂端的10010個結果。然后請求節點排序這50050個結果並丟棄50040個！
簡易搜索
search API有兩種表單：一種是“簡易版”的查詢字符串(query string)將所有參數通過查詢字符串定義，另一種版本使用JSON完整的表示請求體(request body)，這種富搜索語言叫做結構化查詢語句（DSL）。
查詢字符串搜索對於在命令行下運行特定情況下查詢特別有用。例如這個語句查詢所有類型為tweet並在tweet字段中包含elasticsearch字符的文檔：
GET /_all/tweet/_search?q=tweet:elasticsearch
下一個語句查找name字段中包含"john"和tweet字段包含"mary"的結果。實際的查詢只需要：
+name:john +tweet:mary
但是url編碼需要將查詢字符串參數變得更加神秘：
GET /_search?q=%2Bname%3Ajohn+%2Btweet%3Amary
"+"前綴表示語句匹配條件必須被滿足。類似的"-"前綴表示條件必須不被滿足。所有條件如果沒有+或-表示是可選的——匹配越多，相關的文檔就越多。
_all字段
返回包含"mary"字符的所有文檔的簡單搜索：
GET /_search?q=mary
當你索引一個文檔，Elasticsearch把所有字符串字段值連接起來放在一個大字符串中，它被索引為一個特殊的字段_all。例如，當索引這個文檔：
{
"tweet": "However did I manage before Elasticsearch?",
"date": "2014-09-14",
"name": "Mary Jones",
"user_id": 1
}
這好比我們增加了一個叫做_all的額外字段值：
"However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1"
若沒有指定字段，查詢字符串搜索（即q=xxx）使用_all字段搜索。
更復雜的語句
下一個搜索的語句：
_all field
- name字段包含"mary"或"john"
- date晚於2014-09-10
- _all字段包含"aggregations"或"geo"
+name:(mary john) +date:>2014-09-10 +(aggregations geo)
編碼后的查詢字符串變得不太容易閱讀
?q=%2Bname%3A(mary+john)+%2Bdate%3A%3E2014-09-10+%2B(aggregations+geo)
就像你上面看到的例子，簡單查詢字符串搜索驚人的強大。允許我們簡潔明快的表示復雜的查詢。這對於命令行下一次性查詢或者開發模式下非常有用。
然而，你可以看到簡潔帶來了隱晦和調試困難。而且它很脆弱——查詢字符串中一個細小的語法錯誤，像-、:、/或"錯位就會導致返回錯誤而不是結果。
最后，查詢字符串搜索允許任意用戶在索引中任何一個字段上運行潛在的慢查詢語句，可能暴露私有信息甚至使你的集群癱瘓。
取而代之的，生產環境我們一般依賴全功能的請求體搜索API，它能完成前面所有的事情，甚至更多。
轉載請注明出處。
作者：wuxiwei
出處：http://www.cnblogs.com/wxw16/p/6171016.html