查不到分片键时mongodb会广播查询到所有shard，导致全量扫描、延迟激增；需通过sh.status()和getsharddistribution()确认分片实效性，修复核心是确保查询带分片键或重构分片策略。
查不到分片键时，MongoDB 会自动广播到所有 Shard
当查询条件里没带分片键（或分片键字段缺失、值为 null / undefined），mongos 就无法路由到具体 Shard，只能把请求发给每个 Shard —— 这就是“广播查询”。结果是：原本该查 1/8 数据的请求，实际扫了全部 8 个 Shard 的全量集合，延迟直接翻倍甚至更高。
- 典型现象：
explain("executionStats")显示nReturned很小，但totalDocsExamined或totalKeysExamined高得离谱，且shards字段下出现多个 Shard 的执行记录 - 常见场景：前端传参遗漏字段（如查用户却没传
userId）、聚合管道中$lookup后丢失分片键上下文、旧数据文档缺失分片键字段 - 注意：
find({})或find({status: "active"})这类无分片键条件的查询，在分片集群上默认就是广播行为，不是 bug，是设计如此
sh.status() 和 db.collection.getShardDistribution() 必须先看
别急着改代码，先确认分片是否真在干活。很多“慢”其实是假象——数据根本没分片成功，全堆在 primary shard 上。
- 运行
sh.status()：检查chunks是否已分配、balancer是否开启、各 Shard 的docs数量是否明显不均（比如一个 shard 占 95%，其余都是 0） - 运行
db.users.getShardDistribution()（替换为你的集合名）：看实际数据分布。如果返回只有 1 行，说明压根没分片；如果某 shard 的size是其他 shard 的几十倍，大概率是分片键基数太低（比如用status: "active"分片） - 特别注意：
getShardDistribution()不实时，它读的是 config server 的元数据缓存，刚写入的数据可能还没触发 chunk 拆分，别立刻下结论
C# Driver 查询缺失分片键时，别依赖 Find() 直接拿结果
用官方 C# Driver 发起无分片键查询，它不会报错，但会静默走广播路径——你看到的响应时间，是所有 Shard 返回结果的总耗时 + mongos 合并开销。
- 必须加
.Explain()看执行计划：collection.Find(...).Explain()，重点盯executionStages.shards数组长度和各 shard 的executionTimeMillisEstimate - 避免在业务逻辑里做去重：C# Driver 不会自动 dedup 广播结果，如果多个 shard 返回相同
_id（比如因 chunk 迁移未完成），你得自己用Distinct("_id")或内存去重，这又多一层开销 - 临时补救法（仅限调试）：在查询前强制指定读偏好
ReadPreference.Nearest，但这不能解决广播本质，只影响 mongos 选哪个 shard 发请求，对性能提升微乎其微
修复不是加索引，而是让查询「带上分片键」或「重构分片策略」
索引再好，也救不了广播查询。真正的解法只有两个方向：要么让每次查询都携带分片键，要么承认当前分片键已失效，换掉它。
- 短期止血：在应用层加校验，比如 C# 里写
if (filter.UserId == null) throw new ArgumentException("分片键 UserId 缺失")，比让它跑进数据库强十倍 - 数据迁移补救：若历史数据大量缺失分片键字段，别用
$set批量更新（可能触发 chunk 搬家风暴），改用 DTS 工具同步时配置默认分片键值（阿里云 DTS 支持该能力），或先导出-补字段-再导入 - 换分片键代价极高：需停写、dump、修改 config、重新
shardCollection，且 MongoDB 不支持在线更换分片键。所以一开始选错，后面基本只能接受“部分查询永远慢”这个事实
最容易被忽略的一点：分片键不是设完就一劳永逸的。当业务增长后，原来均匀的键（比如 userId）可能因批量注册、爬虫刷号导致局部热点，这时候光看 sh.status() 里的 chunk 数量没用，得结合 db.printShardingStatus() 看单个 chunk 大小是否突破 128MB 上限——那才是性能拐点。
