find() 会广播到所有分片是因为查询未包含分片键完整前缀，导致 mongos 无法定位目标分片，只能向所有分片发送请求，引发性能下降。
为什么 find() 会广播到所有分片？
当你执行没有 _id 或分片键（shard key）条件的 find() 查询时，mongos 无法判断数据落在哪个分片上，只能把请求发给所有分片——这就是“广播查询”。典型触发场景包括：db.users.find({ status: "active" })，而 status 不是分片键，也不是 _id。
广播不仅拖慢响应，还会放大网络和 CPU 压力，尤其在分片数多、数据量大的集群中更明显。
- 分片键未被包含在查询条件中（哪怕只是
$or里没覆盖全） - 用了非前缀匹配的复合分片键，比如分片键是
{ region: 1, user_id: 1 }，但只查{ user_id: 123 } - 查询用了
$text、$regex（非锚定开头）、$where等无法下推到分片的运算符
如何让 mongos 路由到单个分片？
核心原则：让查询条件能唯一或精确地映射到一个分片范围（chunk range）。这依赖于分片键的结构和查询写法。
- 必须包含分片键的**完整前缀字段**，且用等值（
$eq）或范围（$gte/$lte）操作——例如分片键为{ org_id: 1, created_at: -1 }，则{ org_id: "org-001" }可路由，但{ created_at: { $gt: ISODate("...") } }会广播 - 避免在分片键字段上使用
$ne、$not、$in（含空数组或大量值）——这些通常无法精准定位 chunk - 对
_id字段的查询只有在_id是分片键，或启用了hashed _id分片时才可路由；否则仍是广播 - 使用
explain("executionStats")检查executionStages.shards数量，确认是否只访问了预期分片
哪些索引能帮上忙？
索引本身不改变路由行为，但能减少单个分片内的扫描开销。真正影响路由的是查询是否命中分片键——索引只是后续优化。
- 在分片键上建索引是自动的，无需额外操作
- 若常用查询带
org_id+status，而分片键是{ org_id: 1 }，可在各分片上手动建{ org_id: 1, status: 1 }索引，加速过滤 - 避免在非分片键字段建高开销索引（如长文本
$text），它不会阻止广播，反而增加写入负担 - 注意：
unique约束要求唯一键必须包含分片键全部字段（或为_id），否则创建失败
实际排查与验证步骤
别靠猜，用工具直接看 mongos 怎么发请求。
- 在 mongos 上执行：
db.users.find({ org_id: "org-001", status: "active" }).explain("executionStats")，检查返回里的shards数组长度是否为 1 - 开启慢查询日志：
db.setProfilingLevel(1, { slowms: 100 })，再查一次，然后去system.profile看keysExamined和docsExamined是否集中在单分片 - 用
mongostat观察各分片的qr（queued reads）是否同步飙升——广播时所有分片qr都会跳 - 如果用了聚合管道，确保
$match阶段放在最前面，且条件含分片键；$lookup跨集合时，被 lookup 的集合也需合理分片，否则照样广播
最容易被忽略的是复合分片键的“前缀性”——少一个字段，就从精准路由退化成广播，而且错误往往在业务逻辑分散处，不容易一眼发现。
