count()在副本集上慢且无法读写分离，因其强制路由至primary、不走索引、不支持secondary执行；替代方案是$group+$sum聚合，需配合readPreference="secondary"和readConcern="available"方可生效。
count() 在副本集上为什么慢得反常
因为默认走主节点，且不走索引——db.collection.count() 本质是全集合扫描，哪怕有索引也不会用。更糟的是，如果在从节点执行（比如配了 readPreference: "secondary"），MongoDB 会直接报错：Command count not supported from secondary。这不是配置问题，是设计限制：count 命令强制路由到 primary，且无法并行化。
替代方案：用聚合管道 + $group 替代 count()
真正能绕过限制、支持读写分离、还能利用索引的，是 $group 配合 $sum: 1。它会被下推到各分片（或副本集成员）本地计算，再由 mongos（或 primary）聚合结果。
-
db.collection.aggregate([{$group: {_id: null, total: {$sum: 1}}}])—— 等价于 count()，但可走 secondary（需显式指定 readConcern 和 readPreference） - 如果带查询条件，
$match必须放在$group前面，否则无法利用索引 - 注意：
_id: null是必须的占位，不能省略；否则会按实际 _id 分组，结果不是总数
必须加的两个配置才能让聚合 count 走从节点
光用聚合还不够。默认情况下，即使语法合法，MongoDB 仍可能拒绝在 secondary 上执行含 $group 的聚合——除非你明确告诉它“可以容忍短暂不一致”。
- 设置
readPreference: "secondary"（驱动层或 shell 中用rs.secondaryOk()） - 设置
readConcern: "available"（不是"majority"）——这是关键，"available"表示读取当前节点已落盘的最新数据，不等 oplog 同步完成，才能在 secondary 上跑聚合 - 遗漏任一配置，都会 fallback 到 primary，失去读写分离意义
真实压测中容易被忽略的瓶颈点
即便聚合 count 跑在 secondary 上，高并发下仍可能卡住——问题往往不出在查询本身，而在底层资源争抢。
- oplog 太小：如果
oplogSizeMB小于 24 小时写入量，secondary 同步延迟飙升，readConcern: "available"可读的数据就变少甚至为空，聚合反而超时 - 从节点没开并行同步：MongoDB 4.4+ 默认启用，但旧版本或手动关闭后（
enableMajorityReadConcern: false），聚合会串行处理每个 chunk，吞吐直线下跌 - count 场景误用了
$facet：有人想同时查总数+分页数据，用$facet包两套 pipeline，这会导致整个聚合无法下推，全部拉到 mongos 内存里算——千万避免
最稳的路子是：条件允许时，用带 TTL 的缓存字段（如 stats.total_count）定期更新，而不是每次请求都实时 count。聚合 count 是兜底手段，不是常规解法。
