在Elasticsearch中，“ match”查询和“ should”子句的匹配结果超出了要求

让我们通过以下映射来了解这一点，例如：

{  "_doc": {    "properties": {      "Id": {        "type": "text",        "fields": {          "keyword": { "type": "keyword", "ignore_above": 256          }        }      },      "Name": {        "type": "text",        "fields": {          "keyword": { "type": "keyword", "ignore_above": 256          }        }      }    }  }}

上面的映射是由elasticsearch动态创建的。现在让我们专注于

Id

领域。其类型为

text

。默认情况下，

analyzer

for

text

数据类型为

standard

Analyzer。当将此分析器应用于此字段的输入时，它将被标记为术语。因此，例如，如果您输入的值

Id

是，则会

33f87d98-024f-4893-aa1c-8d438a98cd1f

生成以下令牌：

33f87d98024f4893aa1c8d438a98cd1f

如您所见，输入值

-

被用作定界符进行拆分。这是因为在其上应用了标准分析仪。

还有另外一个子场下，

Id

这是

keyword

和它的类型

keyword

。对于类型

keyword

，输入将按原样编制索引，而无需进行任何修改。

现在让我们了解为什么要匹配更多文档并且结果计数超出预期。在查询中，您

match

对

Id

字段使用了查询，如下所示：

{  "match": {    "Id": "b8bf49a4-960b-4fa8-8c5f-a3fce4b4d07b"  }}

默认情况下，匹配查询使用与映射中的字段相同的分析器。因此，

Id

再次对查询中的值应用相同的分析器，并且以与上述类似的方式将输入拆分为令牌。在匹配查询输入字符串的标记之间应用的默认运算符为OR，因此您的查询实际上变为：

b8bf49a4 OR 960b OR 4fa8 OR 8c5f OR a3fce4b4d07b

如果上述任何标记与

Id

字段中存储的任何索引词匹配，则该文档被视为匹配。

基于以上映射的以上解决方案：

请改用关键字字段。因此查询变为：

{  "match": {    "Id.keyword": "b8bf49a4-960b-4fa8-8c5f-a3fce4b4d07b"  }}

有关匹配如何工作的更多信息，请参见此处。

也正如@Curious_MInd在他的回答中提到的那样，使用它

terms

比使用

match

in 更好

should

。