Elasticsearch相同查询返回不同hits total问题求助（5.5.x版本）

针对你遇到的这个奇怪情况——对一个无新文档写入的只读索引，用preference=_primary指定只查主分片，相同的match查询却返回不同的hits.total，我结合Elasticsearch 5.5.x的特性整理了几个可能的原因和对应的排查/解决方法：

1. 后台段合并导致的临时计数波动 #

即使没有新文档写入，Elasticsearch后台仍会自动执行段合并操作：把多个小索引段合并成大段，同时彻底清理标记为删除的文档。在合并过程中，主分片的文档统计可能出现短暂不一致——比如合并前的统计包含了已标记删除但未清理的文档，合并后这些文档被移除，导致hits.total减少。

排查与解决： #

• 查看索引的段信息，确认是否有合并正在进行：

  GET app-wechat-2018.04.16/_segments
  

• 等待合并完成后再查询，结果通常会稳定。如果需要快速解决，也可以手动触发仅清理已删除文档的合并（注意：大索引执行此操作会消耗较多资源）：

  POST app-wechat-2018.04.16/_forcemerge?only_expunge_deletes=true
  

2. Elasticsearch 5.5.x的已知版本bug #

5.5.x属于较老的版本，存在一些关于文档计数、查询准确性的bug。比如某些场景下，主分片的元数据统计与实际文档数不一致，或者match查询在特定分词逻辑下出现计数偏差。

排查与解决： #

• 检查当前版本是否在补丁修复范围内：5.5.3及后续小版本修复了部分计数相关问题，如果你的版本较低，建议升级到同系列的最新小版本。
• 强制刷新索引，更新统计信息：

  POST app-wechat-2018.04.16/_refresh
  

3. 查询上下文或隐式参数的差异 #

虽然看起来执行的是相同查询，但可能存在隐式差异：比如请求是否携带了未注意到的参数（比如track_total_hits的默认值被修改，不过5.x默认是精确计数），或者集群主分片发生了临时故障转移（不过用preference=_primary的话，主分片故障会直接导致查询失败）。

排查与解决： #

• 确保每次查询的URL和请求体完全一致，可将查询保存为脚本重复执行对比结果。
• 检查索引所在分片的稳定性：

  GET _cluster/health/app-wechat-2018.04.16
  

4. 已删除文档的残留计数干扰 #

如果这个索引曾经有过删除操作，已删除的文档可能残留在未合并的段中，部分查询会误统计这些文档，段合并后又被清理，导致计数变化。

排查与解决： #

• 使用_countAPI直接统计匹配文档数，对比搜索结果的hits.total：

  GET app-wechat-2018.04.16/_count
  {
    "query": {
      "match": {
        "message": "maidian"
      }
    }
  }
  

• 如果_count结果稳定但_search的hits.total不稳定，大概率是段合并或统计缓存问题，执行_forcemerge后即可解决。

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