使用terms_set查询时Elasticsearch查询缓慢的优化求助

索引包含250万条文档，使用terms_set查询sentence字段匹配至少1个指定词时，耗时约10秒，Search Profiler显示大部分时间消耗在create_weight阶段。以下是针对性优化方案：

一、替换查询类型，简化逻辑开销 #

你的查询中minimum_should_match_field固定为1，本质是匹配任意一个指定term，完全可以用更轻量的terms查询替代terms_set，避免terms_set额外的动态匹配数计算逻辑，直接降低create_weight阶段的处理成本。

替换后的查询语句：

{
  "query": {
    "terms": {
      "sentence": ["FZC", "KNP", "YST", "..."] // 去重后的term列表
    }
  },
  "_source": ["name"], // 只返回需要的字段，减少序列化开销
  "size": 1000 // 根据需求限制返回结果数
}

二、优化索引配置 #

1. 调整分片数量
   当前3个分片，每个分片承载约83万文档。如果集群CPU资源充足，可适当增加分片数（如5-6个），降低单个分片的查询压力，提升并行查询效率，减少单分片上create_weight的处理时间。
   修改索引设置（需关闭索引后修改，再重新打开）：

PUT /your_index/_settings
{
  "index": {
    "number_of_shards": 5
  }
}

2. 减少副本数或指定查询主分片
   当前副本数为2，过多的副本会增加查询时的节点间请求开销。若业务对高可用要求可降低，可将副本数改为1；或者在查询时指定仅查询主分片，避免轮询副本的额外消耗：

{
  "query": {
    "terms": { "sentence": ["..."] }
  },
  "preference": "_primary"
}

3. 开启查询缓存
   若你的查询term列表重复率高，可开启索引的查询缓存，将查询结果缓存起来，避免重复执行create_weight等阶段：

PUT /your_index/_settings
{
  "index.queries.cache.enabled": true
}

查询时启用缓存：

{
  "query": { "terms": { "sentence": ["..."] } },
  "request_cache": true
}

三、优化查询参数 #

1. 去重term列表
   你的terms列表存在重复值（如VMI出现两次），先对term列表去重，减少create_weight阶段需要处理的term数量，直接降低该阶段耗时。

2. 限制返回字段与结果数
   通过_source指定仅返回业务需要的字段（如name），减少数据序列化和传输的开销；同时用size限制返回结果的数量，避免处理大量结果带来的额外耗时。

四、硬件与集群配置优化 #

• 提升CPU资源：create_weight阶段属于CPU密集型操作，增加节点的CPU核心数（如从4核提升至8核以上），能显著加快该阶段的处理速度。
• 优化JVM堆内存：将Elasticsearch的JVM堆内存设置为物理内存的50%（最大不超过32GB），避免GC频繁触发导致的性能波动。
• 使用SSD存储：SSD的随机IO性能远优于HDD，能加快倒排索引的读取速度，间接降低查询各阶段的耗时。

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