ElasticSearch之匹配查询operator和minimumShouldMatch用法详解

目录

使用场景

我现在有两个字段参与索引，文件名称和文件索引。

搜索的时候，一个关键字匹配查询两个字段。

思路分析

众所周知，匹配查询先分词再查询。

单字段查询比较简单，下边有两个例子，一个单字段，一个多字段布尔匹配查询。

假如单字段查询关键字为“万里长城真伟大”。

注意：

在这个测试过程中，我没有使用Kibana进行测试，我是直接使用java代码测试的，结果是一样的。

为什么不使用Kibana呢？原因如下：

Kibana语法，每次写的时候，我都是打开Kibana文档，直接复制粘贴，改改就用，不是我吹，应该没几个人能背的下来吧，而且Kibana的格式要求很严格，纯手写能写出来的都是秀儿。所以我不想再看文档了，反正手头上有代码，直接写完事儿。

查询第一步：分词

{
  "tokens": [
    {
      "token": "万里长城",
      "start_offset": 0,
      "end_offset": 4,
      "type": "CN_WORD",
      "position": 0
    },
    {
      "token": "万里",
      "start_offset": 0,
      "end_offset": 2,
      "type": "CN_WORD",
      "position": 1
    },
    {
      "token": "万",
      "start_offset": 0,
      "end_offset": 1,
      "type": "TYPE_CNUM",
      "position": 2
    },
    {
      "token": "里长",
      "start_offset": 1,
      "end_offset": 3,
      "type": "CN_WORD",
      "position": 3
    },
    {
      "token": "里",
      "start_offset": 1,
      "end_offset": 2,
      "type": "COUNT",
      "position": 4
    },
    {
      "token": "长城",
      "start_offset": 2,
      "end_offset": 4,
      "type": "CN_WORD",
      "position": 5
    },
    {
      "token": "真",
      "start_offset": 4,
      "end_offset": 5,
      "type": "CN_CHAR",
      "position": 6
    },
    {
      "token": "伟大",
      "start_offset": 5,
      "end_offset": 7,
      "type": "CN_WORD",
      "position": 7
    }
  ]
}

查询第二步：匹配

匹配查询中要用到两个参数。

operator：默认为or。

minimumShouldMatch：默认为1。

重点API：operator

在上边万里长城真伟大这个查询中，如果operator为or，为and会有什么不同的区别呢。

为or时：

索引库中，只要文档的content这个字段内容包含“万里长城”，“里”，“真”，“伟大”等任何一个分词，该条文档就会被索引到。

为and时：

索引库中，文档的content这个字段必须包含“万里长城”，“里”，“真”，“伟大”等所有分词 ，这就是and。

看下边的测试，多字段匹配兼布尔should查询。很明显and时候，更加准确。

重点API：minimumShouldMatch

在上边万里长城真伟大这个查询中，如果minimumShouldMatch为0，为1，为10会有什么不同的区别呢。

明确两点：

第一：

只有operator为or时，minimumShouldMatch才有效。

毕竟operator为and时，要求全部都匹配上，都要满足，minimumShouldMatch这边你又设置了只要满足两个词条就可以返回，两个条件冲突了。

第二：

minimumShouldMatch这个api的主要目的是为了避免搜索不精确，比如万里长城真伟大。

如果索引库中一个文档的内容中，包含“真”字就返回了，这就不科学了。

为0时：

是不是猜测，为0的时候，一个都不用匹配到，就可以返回。

然而结果是残酷的，我设置了为0，并不是全部返回，还是要有一个匹配的词条才会返回。

​ ES对这个api还是有所限制的，毕竟如果返回全部内容的话，ES检索没有意义。

为1时：

正常默认情况下，就是为1。

为10时：

你的关键字能分为10个词条吗，字段里的内容如果分词后能有10个词条，可以返回。

设置为10的时候，很多东西会搜索不出来，返回结果数量为0。

关于这个测试，我将测试结果，截图放在这里。

最左侧是搜索关键字，仅仅搜索文件内容这一个字段，设置不同minimumShouldMatch的大小，看不同的结果。

观察发现：

1、为1和为0都一样，ES对这个API有处理。

2、为10时，我发现很多关键字都搜索不出来结果，所以我缩小为4，缩小为2，结果慢慢就出来了。慎用。

3、我发现金融两个字，都是125条数据，很纳闷，一开始我以为因为是法规库，所以字段内容金融两字确实比较多，所以显示出来，然后我又试了将大小调整为100,1000，还是125条数据，我就 悟了 。

我对金融进行分词，看看金融的分词结果，金融不参与分词，分词词条数量这个API对它无效。

··········································································

一家之言，当不得真，有错误的地方，感谢指出。