countdocuments慢的根因是未命中索引或分片协调开销，应建匹配filter的复合索引、停balancer并hint\_id\_索引，1800万+文档须改用写时更新计数文档或时间桶预计算。
countDocuments慢，先看是不是没走索引
直接执行 countDocuments 却耗时几秒甚至十几秒，大概率是查询条件没命中有效索引。MongoDB 不会自动为任意字段组合建索引，filter 里有多个字段（比如 {"userid": 123, "height": 180}），就得建对应顺序的复合索引。
检查方式：用 explain("executionStats") 包裹你的 countDocuments 调用，重点看 executionStages.stage 字段：
- 出现
COLLSCAN→ 没走索引，全表扫了 - 出现
IXSCAN但nReturned远小于totalDocsExamined→ 索引字段顺序或覆盖不匹配
修复建议：
- 按查询 filter 中字段的使用频率和选择性排序建索引，高选择性字段放前面（如
userid通常比height更唯一） - 示例：对
{"userid": 123, "height": 180}，优先建{ "userid": 1, "height": 1 }，而不是反过来 - 避免在索引中包含低选择性字段（如
status: "active"），除非它总是和高选择性字段一起查
分片集群下 countDocuments 必须停 balancer + 加 hint
在分片环境里，countDocuments 默认行为是协调所有 shard 扫描，但若 balancer 正在迁移 chunk，结果可能重复或遗漏；即使 balancer 停了，不加 hint 也可能因缺失 _id_ 索引而退化为集合扫描。
必须做的两件事：
- 执行前确认
sh.isBalancerRunning()返回false，否则跳过 - 显式传
options.Count().SetHint("_id_")（Go 驱动）或hint={"_id_": 1}（PyMongo），强制走主键索引加速游标遍历 - 设
maxTimeMS=30000，防长尾阻塞；超时就报错，别让它卡住整个请求链
注意：count() 和 estimated_document_count() 在分片下不准，不是慢的问题，是语义缺陷——它们读的是各 shard 的元数据快照，迁移中天然不可靠，业务逻辑里绝对不能用。
1800 万+ 文档量级，别依赖实时 count
哪怕加了完美索引，countDocuments(filter) 在 1800 万+ 文档的集合上，稳定耗时也在 8–200ms 区间波动。这不是调优能抹平的，是 WiredTiger 引擎在分片协调下的硬开销。
真实线上场景该怎么做：
- 把「每次读都算」改成「写时更新 + 读时取缓存」：为每个
userid维护一条计数文档，结构如{ _id: "user_123", count: 42, updated_at: ISODate() } - 所有写操作（insert/update/delete）必须同步用
updateOne(..., { upsert: true, upsert: true })原子增减count字段 - 读取直接
findOne({ _id: "user_123" })，毫秒返回，不走 mongos 协调 - 每天凌晨跑校准 job，对比
countDocuments(filter)和计数文档值，差值超 0.1% 就触发修复
容易被忽略的关键点：计数文档的 _id 必须按业务维度拆分（如用户、时间桶），绝不能用全局 "total" —— 高并发写会打满单个 shard 的 write lock。
聚合类统计别硬 count，改用时间桶模型
要查「过去 7 天每小时订单量」这种带时间窗口的聚合，千万别写 aggregate([...{$match}, {$group: {_id: {$dateToString: {...}}, count: {$sum: 1}}...])。它无法用索引加速，每次都要扫全量，且结果不可缓存。
正确做法是预计算 + 时间桶：
- 桶 ID 用 UTC 整点时间字符串，如
"2026-07-21T08:00:00Z" - 写入订单时，用
updateOne({ _id: bucketId }, { $inc: { order_count: 1 } }, { upsert: true }) - 查最近 24 小时，只用
find({ _id: { $gte: "2026-07-20T09:00:00Z" } })，6 行代码搞定 - 给计数文档加 TTL 索引：
createIndex({ updated_at: 1 }, { expireAfterSeconds: 86400 })，自动清理陈旧条目
时间桶模型的成败关键在于写入时桶 ID 的生成逻辑是否严格对齐、是否统一用 UTC、是否所有服务时钟同步——漏掉一个，聚合结果就断层。
