這裡有一個地方注意的是官方文件裡面給的例子的json結構只是一部分，並不是可以直接黏貼複製進去使用的。一般要在外面加個query為key的機構。

match

最簡單的一個match例子：

查詢和"我的寶馬多少馬力"這個查詢語句匹配的文件。

{ "query": { "match": { "content" : { "

上面的查詢匹配就會進行分詞，比如"寶馬多少馬力"會被分詞為"寶馬 多少 馬力", 所有有關"寶馬 多少 馬力", 那麼所有包含這三個詞中的一個或多個的文件就會被搜尋出來。
並且根據lucene的評分機制(TF/IDF)來進行評分。

match_phrase

比如上面一個例子，一個文件"我的保時捷馬力不錯"也會被搜尋出來，那麼想要精確匹配所有同時包含"寶馬 多少 馬力"的文件怎麼做？就要使用 match_phrase 了

完全匹配可能比較嚴，我們會希望有個可調節因子，少匹配一個也滿足，那就需要使用到slop。

{ "query": { "match_phrase": { "content" : { "query" : "我的寶馬多少馬力", "slop" : 1 } } }}

multi_match

如果我們希望兩個欄位進行匹配，其中一個欄位有這個文件就滿足的話，使用multi_match

但是multi_match就涉及到匹配評分的問題了。

{ "query": { "multi_match": { "query":"我的寶馬發動機多少", "type":"best_fields", "fields": [ "tag","content" ], "tie_breaker":0.3 } }}

意思就是完全匹配"寶馬 發動機"的文件評分會比較靠前，如果只匹配寶馬的文件評分乘以0.3的係數

我們希望越多欄位匹配的文件評分越高，就要使用most_fields

我們會希望這個詞條的分詞詞彙是分配到不同欄位中的，那麼就使用cross_fields

{ "query": { "multi_match": { "query":"我的寶馬發動機多少", "type":"cross_fields", "fields": [ "tag","content" ] } }}

-------------------------------------------------------------------------------------------------------------------

term是代表完全匹配，即不進行分詞器分析，文件中必須包含整個搜尋的詞彙

{ "query": { "term": { "content":"汽車保養" } }}

查出的所有文件都包含"汽車保養"這個片語的詞彙。

使用term要確定的是這個欄位是否“被分析”(analyzed)，預設的字串是被分析的。

拿官網上的例子舉例：

mapping是這樣的：

PUT my_index/my_type/1{"full_text":"Quick Foxes!","exact_value":"Quick Foxes!" }

其中的full_text是被分析過的，所以full_text的索引中存的就是[quick, foxes]，而extra_value中存的是[Quick Foxes!]。

那下面的幾個請求：

GET my_index/my_type/_search{"query": { "term": { "full_text":"Quick Foxes!" } }} 請求不出資料的，因為full_text分詞後的結果中沒有[Quick Foxes!]這個分詞。

bool聯合查詢: must,should,must_not

如果我們想要請求"content中帶寶馬，但是tag中不帶寶馬"這樣類似的需求，就需要用到bool聯合查詢。
聯合查詢就會使用到must,should,must_not三種關鍵詞。

這三個可以這麼理解

• must: 文件必須完全匹配條件
• should: should下面會帶一個以上的條件，至少滿足一個條件，這個文件就符合should
• must_not: 文件必須不匹配條件

比如上面那個需求：