countDocuments({}) 比 estimatedDocumentCount() 慢，因其逐 shard 扫描 _id 索引、走事务快照并合并结果；后者仅读各 shard 内存中 ns->nrecords 元数据，无磁盘 I/O 与一致性开销。
countDocuments({}) 为什么比 estimatedDocumentCount() 慢
因为它真正在数——逐 shard 扫描 _id 索引项、走事务快照、合并结果；而 estimatedDocumentCount() 只是读各 shard 内存里的 ns->nrecords 元数据，连磁盘都不碰。
分片集群里慢得特别明显，因为要协调所有 shard
在分片环境下，countDocuments({}) 的耗时主要来自三块：
- 每个 shard 必须在自己的快照下执行游标遍历，不能复用缓存（尤其当
readConcern: "snapshot"开启时） - mongos 要等最慢的那个 shard 返回，长尾效应放大整体延迟
- 如果 balancer 正在运行，部分 shard 可能返回迁移中临时不一致的计数，驱动层还得重试或校验
而 estimatedDocumentCount() 就是让所有 shard 同时报一个整数，加起来完事，网络往返少、无一致性约束。
interactive-document-writing
下载
通过全交互式问答对话，逐章节完成长文档的创建、编写和审计。适用于白皮书、方案书、用户手册、分析报告等需要深度共创的文档。 当用户提到"交互式写文档"、"一起写白皮书"、"逐章讨论"、"Step by Step写文档"、"帮我写方案书/报告/手册"， 或者用户想通过问答方式完成任何长文档编写时，使用此技能。即使用户...
不加 hint 时可能退化成全表扫描
countDocuments({}) 默认不强制走索引，遇到没建有效索引的集合，就会 fallback 到 collection scan：
- 必须显式传
bson.D{}，不能传nil或省略 filter，否则 PyMongo/Node.js 驱动直接报TypeError - 加
SetHint("_id_")是最稳的选择：所有集合都有_id索引，且它唯一、紧凑、B-tree 结构利于快速跳过 - 即使你有复合索引，不 hint 也可能被 query planner 选错——比如选了带
$text的索引，反而更慢
explain 显示 IXSCAN 也不代表快
跑 explain("executionStats") 看到 "stage": "IXSCAN" 很容易误判，关键要看这两个字段：
-
"totalDocsExamined"如果远大于"nReturned"（比如 100 万 vs 1），说明索引只用了排序或等值部分，范围条件仍导致大量回表过滤 -
"executionTimeMillis"高但"totalKeysExamined"很低，大概率是 mongos 协调开销或网络聚合瓶颈，不是单个 shard 慢 - 真正快的 count，是连文档都不读——靠索引项数量推算。但 MongoDB 从不保证对
countDocuments({})做这种优化
业务里别把 estimatedDocumentCount() 当精确值用，它连迁移中的孤儿文档都看不见，更别说事务内未提交的数据。
