Elasticsearch 1.5 must_not过滤器间歇性失效问题求助

先给你拆解下这个问题的核心点，结合ES 1.5的特性和你的查询语句，大概率是这几个原因导致的间歇性失效：

1. 查询结构不合理：多term should不如用terms查询 #

你当前的查询在must_not里嵌套了一个包含大量term的bool should，这种写法在处理10000个erpNumber值时，会生成异常庞大的查询DSL，ES 1.5对这种复杂嵌套且多值的查询处理能力有限，很容易出现内存溢出、查询逻辑异常的情况，进而导致间歇性失效。

优化方案：把多个term的should替换为terms查询，这是ES专门为多值匹配设计的语法，不仅性能更高，还能避免嵌套查询的逻辑bug：

"filter": {
  "bool": {
    "must": [
      {"term": {"websites": "c2c53320-98dc-4eca-8022-9efc00dea0dc"}},
      {"term": {"languageCode": "en-us"}}
    ],
    "must_not": [
      {"terms": {"erpNumber": ["LIP_LAGSMS", "其他erp值", ...]}}
    ]
  }
}

2. ES 1.5版本过于陈旧，存在已知bug #

Elasticsearch 1.5是非常老旧的版本（停止维护多年），官方早已修复了大量过滤器、bool查询相关的bug，其中就包括部分场景下must_not逻辑失效的问题。老旧版本的稳定性和兼容性都很差，这很可能是间歇性问题的根源。

建议：如果条件允许，尽快升级到较新的稳定版本（比如7.x或8.x），这能从根本上解决很多遗留问题。

3. 字段映射可能存在问题 #

如果erpNumber字段被映射为text类型而非keyword类型，term查询会匹配分词后的子词，而非完整的字段值。这会导致某些情况下你认为应该被拦截的值，实际上因为分词不匹配而没被拦截，看起来像是must_not失效。

检查方式：通过GET /your_index/_mapping查看erpNumber的映射，确保它是keyword类型（或者启用了fielddata的text类型，但更推荐用keyword做精确匹配）。

4. 集群资源不足导致的异常 #

10000个值的terms查询会占用较多内存，如果你的ES集群内存不足、GC频繁，可能会导致查询处理中断或逻辑异常，表现为间歇性失效。

排查方式：查看ES节点的日志文件，检查是否有内存溢出（OOM）、GC超时、查询队列溢出等报错信息。如果有，需要调整JVM堆内存大小或扩容集群资源。

临时验证方案 #

你可以先尝试用简化后的terms查询替换原来的嵌套should，同时观察查询结果是否稳定。如果问题消失，就说明是查询结构导致的；如果问题依然存在，再重点排查版本和资源问题。

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