最常见原因是查询未含分片键导致广播执行；需用explain检查splitpipeline.shards字段，确保定向路由；避免直连mongod、balancer干扰及mongos合并瓶颈。
查询没走定向路由，却在所有分片上广播执行
这是最常见、也最容易被误判为“性能差”的原因。mongos 只有在查询条件包含分片键或其前缀时，才可能做定向路由；否则默认广播到全部 shard。比如片键是 {"vehicle_id": 1, "ts": 1}，但你查 { "status": "offline" } 或 { "ts": { $gt: ISODate("...") } }（没带 vehicle_id），mongos 就只能把请求发给每个 shard，再合并结果——开销自然飙升。
实操建议：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 用
explain: true跑一次聚合或 find，看返回里的splitPipeline.shards字段：如果列出全部 shard，说明是广播；只列 1–2 个，才是定向 - 检查查询是否漏掉了片键的最左字段。即使你加了
vehicle_id，但用了$in查几百个 ID，也可能触发广播（取决于 chunk 分布和选择性） - 避免在应用层拼出“全量扫描式”查询，比如后台导出不加
vehicle_id过滤的 telemetry 数据
聚合管道在 mongos 合并阶段卡住或反复重试
mongos 对聚合的合并逻辑很敏感：一旦管道里有 $lookup 关联未分片集合、或 $group + allowDiskUse: true，它就无法把合并阶段下推到单个分片，必须拉回 mongos 做内存合并。当数据量大、网络延迟高、或 mongos 内存不足时，这个阶段会明显拖慢整体响应。
实操建议：
- 执行
db.runCommand({ aggregate: "...", explain: true })，重点看mergeType字段值：如果是"mongos"，说明合并确实在路由层发生，要警惕 - 把大聚合拆成两步：先在各 shard 上用
$group预聚合（确保不含跨分片依赖），再由应用层收拢结果 - 确认
mongos实例的内存配置（--maxConns、--chunkSize）是否匹配当前吞吐，别让它成为瓶颈节点
balancer 活跃导致 chunk 迁移干扰查询稳定性
虽然 balancer 不直接处理查询，但它在后台持续调用 moveChunk。一旦迁移失败（比如 config server 延迟高、primary 切换中），mongos 的元数据缓存可能短暂过期，导致后续查询路由错乱、重试增多、甚至返回部分结果。你在 sh.status() 里看到某些 shard 的 chunk 数长期远高于其他节点，基本就是信号。
实操建议：
- 运维窗口内手动停掉 balancer：
sh.stopBalancer()，等集群稳定后再开，别让它在高峰时段自动运行 - 检查
config.system.sessions和config.transactions是否积压——这些元数据表过大也会拖慢 config server 响应 - 用
db.adminCommand({ getCmdLineOpts: 1 })确认所有 mongos 是否启用了--enableSharding和一致的chunkSize（默认 64MB），不一致会导致路由判断异常
客户端连接混用 mongos 和 mongod 地址
这是最隐蔽也最致命的配置错误：应用一部分流量走 mongos，另一部分直连某个 mongod 节点。后者完全绕过分片逻辑，查不到其他 shard 的数据，还可能因写入不经过路由层，导致数据分布混乱、索引缺失、甚至引发重复写入冲突。此时你看到的“查询慢”，其实是部分请求根本没进分片流程。
实操建议：
- 立刻检查应用连接字符串：必须是
mongodb://mongos1:27017,mongos2:27017/?replicaSet=rs0这类指向 mongos 的地址，绝不能出现mongodb://shard1-node1:27017这样的直连 - 在 mongos 日志里 grep
"direct connection"或"not connected to a mongos"，确认没有客户端绕过路由层 - 对关键集合执行
sh.status()后，再用db.collection.stats()对比各 shard 上的count和sizeOnDisk，若差异极大，大概率已有直连写入污染
