引言
虽然之前做过 elasticsearch 的项目，但是没有对整个项目的知识点进行过系统的整理。这次趁着对 elasticsearch 版本的升级的机会（从2.2 升级到 6.3) ，又专门花时间对涉及到的知识点重新梳理了一遍。
俗话说，好记性不如烂笔头。为了加深对 elasticsearch 的理解，后面再做类似项目时更容易捡起来，以及对用到的同学提供方便。从本文开始，我会对 elasticsearch Query DSL 的知识点进行梳理。
在讲解时我会尽量以实例代码展示的方式进行最直观的展现。纸上来得终觉浅，绝知此事要躬行。做技术尤其要注重多实践，懂了并不代表你就掌握了。强烈建议有志于深入了解这部分内容的同学，对文中给出的代码实例在 sense 中实践一遍甚至是多遍。
注意： 本文基于 elasticsearch 6.3 版本， 如果您使用的是其他版本，一些内容可能会有所变化，具体使用时还请以官方文档为准
Query DSL 是 elasticsearch 的核心，搜索方面的项目大部分时间都耗费在对查询结果的调优上。因此对 Query DSL 的理解越深入，越能节省项目时间，并给用户好的体验。
概要
Elasticsearch 提供了一个完整的 query DSL，并且是 JSON 形式的。它和 AST 比较类似，并且包含两种类型的语句：
-
叶子查询语句（Leaf Query)
用于查询某个特定的字段，如
match,term或range等 -
复合查询语句 (Compound query clauses)
用于合并其他的叶查询或复合查询语句，也就是说复合语句之间可以嵌套，用来表示一个复杂的单一查询
DSL （domain-specific language），领域特定语言指的是专注于某个应用程序领域的计算机语言，又译作领域专用语言。不同于普通的跨领域通用计算机语言(GPL)，领域特定语言只用在某些特定的领域。
AST（abstract syntax tree), 抽象语法树是源代码的抽象语法结构的树形表现形式。树上的每个节点都表示源代码中的一种结构。之所以说语法是“抽象”的，是因为这里的语法并不会表示出真实语法中出现的每个细节。比如，嵌套括号被隐含在树的结构中，并没有以节点的形式呈现；而类似于if-condition-then这样的条件跳转语句，可以使用带有两个分支的节点来表示。
——百度百科
Query and filter context
一个查询语句究竟具有什么样的行为和得到什么结果，主要取决于它到底是处于查询上下文(Query Context) 还是过滤上下文(Filter Context)。两者有很大区别，我们来看下：
-
Query context 查询上下文
这种语句在执行时既要计算文档是否匹配，还要计算文档相对于其他文档的匹配度有多高，匹配度越高，*_score* 分数就越高
-
Filter context 过滤上下文
过滤上下文中的语句在执行时只关心文档是否和查询匹配，不会计算匹配度，也就是得分。
下面来看一个例子
GET /_search { "query": { "bool": { "must": [ { "match": { "title": "Search" }}, { "match": { "content": "Elasticsearch" }} ], "filter": [ { "term": { "status": "published" }}, { "range": { "publish_date": { "gte": "2015-01-01" }}} ] } } }对上面的例子分析下：
query参数表示整个语句是处于 query context 中bool和match语句被用在 query context 中，也就是说它们会计算每个文档的匹配度（_score)filter参数则表示这个子查询处于 filter context 中filter语句中的term和range语句用在 filter context 中，它们只起到过滤的作用，并不会计算文档的得分。
Match All Query
这个查询最简单，所有的 _score 都是 1.0。
GET /_search { "query": { "match_all": {} } }它的反面就是 Match None Query， 匹配不到任何文档（不知道用它来做什么……）
GET /_search { "query": { "match_none": {} } }全文查询 Full text queries
全文本查询的使用场合主要是在出现大量文字的场合，例如 email body 或者文章中搜寻出特定的内容。
全文查询主要分为下面几种（此处列表中的链接为官方文档链接，后续将各部分讲解后，会替换为讲解链接）：
