ElasticSearch bool/term查询作用于keyword字段时大小写匹配异常咨询

两次查询唯一的差异就是查询值的大小写，和你使用的bool嵌套结构没有任何关系，结果不符合预期本质是两个对ES匹配逻辑的认知错位，核心逻辑如下：

1. name.keyword字段是原生keyword类型，全链路无文本转换能力
   这类字段从索引写入开始，就会把原始文本原封不动作为可匹配的精确值存储，全程不会做大小写归一、分词拆分任何处理。你当前索引里该字段存储的实际值是首字母大写的Finding，因此用term查询逐字符匹配时，传Finding能命中，传全小写的finding因为字符完全不匹配，自然返回空结果。
2. 所谓“ES默认大小写不敏感”有严格的适用边界
   大家普遍认知的大小写不敏感，本质是带小写过滤规则的分词器在text字段上产生的效果：ES默认的标准分词器在把文本写入text字段的倒排索引时，会自动把所有字符转成小写存储，同时match类查询会对入参做完全相同的分词处理，因此不管用户传大写、小写的查询值，最终都能匹配上归一化后的倒排词条，给人一种“全局大小写不敏感”的错觉。
   但term查询是绕过分词器的直连匹配逻辑，尤其是面对keyword类型字段时，从写入到查询全链路都不会经过任何过滤器处理，天生就是严格区分大小写的，不存在默认大小写不敏感的特性。
3. 你当前主name字段的配置也强化了这种区分大小写的行为
   你给主text类型的name字段配置的分析器是keyword，这个分析器本身的逻辑是不对文本做任何拆分、转换，直接把整段原始文本作为一个词条存储，连标准分析器自带的小写过滤功能都没有，哪怕你用term查主name字段，一样会因为大小写差异匹配不到结果。

• 临时不改索引映射的话，ES 7.10及以上版本可以直接给term查询添加case_insensitive: true参数，强制查询时忽略大小写差异，例如把原查询语句里的term部分调整为：

  {"term": {"name.keyword": {"value": "finding", "case_insensitive": true}}}
  

• 长期适配大小写不敏感的精确匹配需求，可以给name字段新增一个带自定义归一化规则的keyword子字段，给该字段配置带小写过滤的normalizer，索引写入时就把所有值统一转成小写存储，后续不管传啥大小写的查询值都能正常命中。
• 如果业务场景不需要严格的精确值匹配，只是要检索包含对应文本的文档，直接用match查询打在主text类型的name字段上即可，只要把主字段的分析器换成带小写过滤的默认标准分析器，match查询天然支持大小写不敏感的匹配效果。

内容的提问来源于stack exchange，提问作者user1187968