我们有一个运行241.047项的索引。这些项目可以包含任意数量的子项目，这些子项目被编入索引作为嵌套文档。子项目总数为381.705。
映射中未设置include_in_parent和include_in_root，这意味着每个嵌套文档都被编入索引作为附加文档。这应该意味着索引中将有总数为241.047 + 381.705 = 622.752的文件。
当我运行以下Curl命令来查找索引中的文档数量时，我会得到一个不同的数字，它离我不远，但我想知道为什么它给了我一个不同的数字并且它没有返回数字我'我期待着。
curl -XGET
'http://localhost:9200/catawiki_development/_status?pretty'返回622.861 接下来，当我运行一个Curl命令来获取根文档的数量时，我获得的数字与我运行match_all查询并询问返回的文档数量不同
curl -XGET 'http://localhost:9200/elasticsearch_development/_count?pretty'返回241.156 match_all查询返回正确数量的文档241.047 如何解释这些差异？
答案 0 :(得分：2)
count api请求的路径与普通搜索请求的路径完全不同。事实上，它是一种快捷方式，只允许获取与查询匹配的文档的计数，即它。它与使用search_type=count的搜索不同，实际上只是搜索的第一部分：将搜索请求广播到所有分片，但没有reduce / fetch，因为我们只想返回匹配文档的总数。您还可以在搜索请求中添加构面等（当使用search_type=count时），这是您无法对count api执行的操作。
那就是说，由于上述原因，我看到差异并不令人惊讶，但要明白究竟是什么问题会很好。最好的方法是能够使用少量文档重现问题，open an issue包括curl recreation，以便我们可以查看它。
与此同时，如果您遇到count api问题，我建议您使用search_type=count的搜索请求。保证返回与普通搜索相同数量的文档，只是因为它是完全相同的逻辑。