match query:

用于执行全文查询的标准查询，包括模糊匹配和短语或者接近查询

控制token之间的布尔关系：operator：or/and

match_phrase query:

与match查询类型，但用于匹配确切的短语或单次接近匹配

token之间的位置距离：slop参数

match_phrase_prefix query:

与match_phrase查询类型，但是会对最后一个token在倒排序索引列表中进行通配符搜索

插入一下数据

插入一下数据：

{ "id" : 1,"content":"关注我,系统学编程" }
{ "id" : 2,"content":"系统学编程,关注我" }
{ "id" : 3,"content":"系统编程,关注我" }
{ "id" : 4,"content":"关注我,间隔系统学编程" }

match query 对应到mysql 

    # DSL 语句
    GET /tehero_index/_doc/_search
    {
      "query":{
        "match":{
          "content.ik_smart_analyzer":"系统编程"
        }
      }
    }

• 检索词“系统编程”被ik_smart分词器分词为两个Token【系统】【编程】；
• 将这两个Token在【倒排索引】中，针对Token字段进行检索，等价于sql：【where Token = 系统 or Token = 编程】；

match_phrase query

match_phrase查询分 析文本并根据分析的文本创建一个短语查询。match_phrase  会将检索关键词分词。match_phrase的分词结果必 须在被检索字段的分词中都包含，而且 顺序必须相同，而且 默认必须都是连续的。

# 使用match_phrase查询，ik_smart分词
GET /tehero_index/_doc/_search
{
    "query": {
        "match_phrase": {
            "content.ik_smart_analyzer": {
            	"query": "关注我,系统学"
            }
        }
    }
}
 
# 结果：只有文档1
{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 0.7370664,
    "hits": [
      {
        "_index": "tehero_index",
        "_type": "_doc",
        "_id": "1",
        "_score": 0.7370664,
        "_source": {
          "id": 1,
          "content": "关注我,系统学编程"
        }
      }
    ]
  }
}

分析：上面的例子使用的 分词器是ik_smart，所以 检索词“关注我，系统学”会被分词为3个Token【关注、我、系统学】；而文档1、文档2和文档4 的content被分词后 都包含这3个关键词，但是 只有文档1的Token的顺序和检索词一致，且连续。所以使用 match_phrase 查询 只能查询到文档1（ps：文档2 Token顺序不一致；文档4 Token不连续；文档3 Token没有完全包含）。 使用 match查询可以查询到所有文档，是因为所有文档 都有【关注、我】这两个Token。

 match_phrase 核心参数：slop 参数-Token之间的位置距离容差值

# 将上面的 match_phrase 查询新增一个 slop参数
GET /tehero_index/_doc/_search
{
    "query": {
        "match_phrase": {
            "content.ik_smart_analyzer": {
            	"query": "关注我,系统学",
            	"slop":1
            }
        }
    }
}
# 结果：文档1和文档4都被检索出来

分析：使用 analyze 接口 分析下文档4的Token
 

# 文档4 content 的分词
GET /_analyze
{
  "text": ["关注我,间隔系统学编程"],
  "analyzer": "ik_smart"
}
# 结果
{
  "tokens": [
    {
      "token": "关注",
      "start_offset": 0,
      "end_offset": 2,
      "type": "CN_WORD",
      "position": 0
    },
    {
      "token": "我",
      "start_offset": 2,
      "end_offset": 3,
      "type": "CN_CHAR",
      "position": 1
    },
    {
      "token": "间隔",
      "start_offset": 4,
      "end_offset": 6,
      "type": "CN_WORD",
      "position": 2
    },
    {
      "token": "系统学",
      "start_offset": 6,
      "end_offset": 9,
      "type": "CN_WORD",
      "position": 3
    },
    {
      "token": "编程",
      "start_offset": 9,
      "end_offset": 11,
      "type": "CN_WORD",
      "position": 4
    }
  ]
}

通过分词测试，发现Token【我】与【系统学】的 position差值为1(等于slop的值 )， 所以文档4也被检索出来了。

match_phrase_prefix query

与match_phrase查询类似，但是 会对最后一个Token在倒排序索引列表中进行通配符搜索。Token的模糊匹配数控制： max_expansions 默认值为50。我们使用 content.ik_smart_analyzer 这个字段中的 【系统学】（文档1、2、4 包含）和 【系统】（文档3包含）这 两个Token来讲解match_phraseprefix 的用法：（因为 使用的是ik_smart分词器，所以【系统学】就只能被分词为一个Token）

# 1、先使用match_phrase查询，没有结果
GET tehero_index/_doc/_search
{
  "query": {
    "match_phrase": {
      "content.ik_smart_analyzer": {
        "query": "系"
      }
    }
  }
}
 
# 2、使用match_phrase_prefix查询， "max_expansions": 1，得到文档3
GET tehero_index/_doc/_search
{
  "query": {
    "match_phrase_prefix": {
      "content.ik_smart_analyzer": {
        "query": "系",
        "max_expansions": 1
      }
    }
  }
}
 
# 3、使用match_phrase_prefix查询， "max_expansions": 2，得到所有文档
GET tehero_index/_doc/_search
{
  "query": {
    "match_phrase_prefix": {
      "content.ik_smart_analyzer": {
        "query": "系",
        "max_expansions": 2
      }
    }
  }
}

结果分析：【语句1】查不到结果，是因为 根据ik_smart分词器生成的倒排序索引中，所有文档中都 不包含Token【系】；【语句2】查询到文档3，是因为 文档3包含Token【系统】，同时 "max_expansions": 1，所以 检索关键词【系】+ 1个通配符匹配，就可以匹配到 一个Token【系统】；【语句3】查询到所有文档，是因为"max_expansions": 2，所以 检索关键词【系】+ 2个通配符匹配，就可以匹配到 两个Token【系统、系统学】，所以就可以查询到所有

注意："max_expansions"的值最小为1，哪怕你设置为0，依然会 + 1个通配符匹配；所以，尽量不要用该语句，因为，最后一个Token始终要去扫描大量的索引，性能可能会很差