不带分片键的查询必然广播，因mongos路由仅依据分片键是否存在来决策；缺失时必须scatter/gather到所有分片，与索引、正则、排序等无关，性能随分片数线性恶化。
不带分片键的查询必然广播，这不是配置问题，而是 mongos 路由机制的硬性限制。
mongos 路由决策只看分片键是否存在
mongos 在收到查询时，第一件事是解析 filter 中是否包含分片键（或其完整前缀）。它不关心字段有没有索引、正则是否高效、$sort 是否合理——只要 filter 里没出现分片键字段，就无法确定目标分片，只能把请求发给所有 shard。
- 例如分片键是
{"userId": 1, "type": 1}，那么{userId: 123}、{userId: 123, type: "order"}是定向的；但{name: "Alice"}或{type: "order"}（缺少前缀userId）都会广播 - 哪怕你给
name字段建了唯一索引，mongos 也完全不利用——它只认分片键 - 写操作同理：
updateMany({status: "pending"}, {...})没带分片键，就是全集群广播写，极易卡住 mongos 的qw队列
缺失分片键字段的文档会集中在一个 chunk，但查询仍可能广播
如果文档本身缺失分片键字段（比如 userId 字段压根不存在），MongoDB 会把它归入 minKey 到 null 的 chunk，通常落在第一个 shard 上。但这只影响数据分布，不影响查询路由逻辑。
-
{userId: null}或{userId: {$exists: false}}这类查询能被路由到那个特定 shard，不会广播 - 但
{name: "Alice"}这种和分片键无关的条件，依然触发 scatter/gather - 也就是说：数据“挤在一起”不等于查询“能定向”，二者解耦
正则、排序、$in 都不改变广播本质
很多开发者误以为加了 $regex 或 $sort 就能“引导”路由，其实 mongos 完全不解析这些操作符的语义。
-
{name: {$regex: "^Alice"}}→ 无分片键 → 广播 -
{userId: 123, name: {$regex: "^Alice"}}→ 有完整分片键前缀 → 定向（前提是分片键是{userId: 1}或{userId: 1, ...}） -
{userId: {$in: [123, 456]}}→ 分片键字段存在且值明确 → 定向（但可能跨多个 chunk，仍只查涉及的 shard） -
{$sort: {createdAt: -1}}单独出现 → 无分片键 → 广播；即使加上{userId: 123}，若createdAt不是分片键，mongos 仍需在目标 shard 内各自排序再 merge，带来额外内存与网络开销
真正容易被忽略的是：广播不是“偶尔慢”，而是每次执行都多出 N 倍网络往返、N 倍结果合并开销，并随分片数线性恶化。一旦业务中出现未带分片键的 find、updateMany 或聚合管道入口无分片键过滤，性能拐点就会突然到来。
