ElasticSearch中Normalizer对Keyword字段查询性能的影响问询

针对你配置的这个仅包含lowercase过滤器的自定义normalizer：

"analysis": {
  "normalizer": {
    "custom_analyzer": {
      "type": "custom",
      "filter": [ "lowercase" ]
    }
  }
}

我来给你拆解下在Keyword类型字段上使用它时的查询性能表现：

索引阶段：核心工作提前完成 #

• 你猜的没错，大部分转换工作都在索引写入时就搞定了：当你给Keyword字段绑定这个normalizer后，Elasticsearch会在文档存入集群的过程中，自动把字段值转换成小写，再写入倒排索引。这一步的额外开销微乎其微——毕竟只是个简单的字符串大小写转换，哪怕是高并发写入场景，这点消耗也不会成为性能瓶颈。

查询阶段：仅需轻量同步转换 #

• 文档里提到的查询时额外操作，其实就是对查询关键词执行和索引阶段完全一致的normalizer处理：比如你输入查询词"HELLO_WORLD"，Elasticsearch会先把它转成"hello_world"，再去倒排索引里匹配已经统一成小写的字段值。这个转换过程非常轻量，单条查询的耗时几乎可以忽略，完全不会拖慢查询速度。
• 更关键的是，因为是Keyword字段，本质还是精确匹配逻辑（只不过是经过normalizer统一后的精确匹配），所以查询的底层性能和原生Keyword字段的精确查询几乎无差——都是直接命中倒排索引的O(1)级查找，效率极高。

整体性能结论 #

• 如果你只是需要实现大小写不敏感的精确查询，这种normalizer+Keyword的方案性能几乎和原生Keyword精确查询一致，唯一的额外开销就是索引和查询时那点微不足道的大小写转换，完全可以忽略。
• 对比用text字段加lowercase分词器的方案，这种组合反而性能更优——因为Keyword字段没有text字段的分词、词项存储等额外开销，存储和查询逻辑都更轻量。

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