好问题！这其实不能一概而论，得结合Elasticsearch的底层索引结构和你的具体查询场景来看，咱们拆解着说：

• 接近常数时间的场景
  如果你的count查询是针对不分词的keyword类型字段做精确匹配（比如用term查询），那这个时候ES根本不需要遍历实际文档。因为倒排索引在构建时，会自动维护每个词项对应的文档统计数（doc count）——这个数值就存在索引的元数据里，查的时候直接取出来就行。加上分片固定的话，每个分片独立取自己的统计数，协调节点再把结果一加，整个过程的时间复杂度几乎就是O(1)，也就是你说的常数时间。

• 无法做到常数时间的场景
  但如果是下面这些情况，count的耗时就会和数据规模、查询复杂度挂钩：

  • 查询的是分词字段（比如text类型）：比如用match查询，ES得先把查询词分词，再去倒排索引里找每个分词对应的postings list，还要处理可能的逻辑合并（比如布尔逻辑），这时候就没法直接拿预存的统计数了。
  • 带有复杂过滤条件：比如range范围查询、多条件bool组合，或者涉及嵌套文档、脚本过滤的查询，ES需要去匹配符合条件的文档，可能要遍历大量的postings list，甚至需要读取磁盘上的文档数据来验证条件，耗时自然会随匹配到的文档量增加而上升。

• 分片的影响补充
  你提到分片数量固定，这点确实很重要：如果每个分片上的查询都是常数时间，那整体耗时就是分片计算时间加协调节点的汇总时间，依然接近常数；但如果分片上的查询本身就不是常数时间，那分片越多，整体耗时也会相应增加（不过是线性增长，不是指数级）。

总结一下：只有当你用term查询不分词的单字段，且没有额外复杂过滤时，count查询才能达到近似常数时间；其他场景下，它的时间复杂度是和查询逻辑、匹配文档量相关的。

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