不带分片键字段的查询会触发广播查询；mongos无法定位目标分片，必须向所有分片发送请求，导致延迟倍增，即使仅需一条结果也需全分片扫描与聚合。
查询没带分片键字段，mongos 就只能广播
定向查询（Targeted Query）失效最常见原因就是查询条件里压根没出现分片键字段。mongos 没法推导目标分片，只能把请求发给所有分片——这就是广播查询，延迟直接翻倍甚至更高。
比如分片键是 {region: 1, userId: 1}，但你只查 {userId: "u123"}，哪怕 region 是高频筛选字段，也照样广播。MongoDB 不支持“仅凭后缀字段路由”。
- 必须显式提供分片键的**完整前缀字段**：对复合分片键
{a: 1, b: 1, c: 1}，至少要带{a: ...}或{a: ..., b: ...}才能定向 - 字段顺序无关，但字段名和存在性必须严格匹配；
{b: ..., a: ...}依然有效 - 用
explain("executionStats")验证：返回中executionStages.shards数量应为 1，且只有那个分片的executionTimeMillisEstimate显著大于 0
分片键字段类型不一致导致路由错位
即使查询写了分片键字段，如果类型和实际存储不一致，哈希计算结果就错，mongos 会把请求发到错误分片，甚至多个分片——看起来像定向失败，实则是类型隐式转换惹的祸。
典型例子：region 字段在集合里混存了 string（如 "us"）和 ObjectId（如 ObjectId("...")），而你查 {region: "us"}，mongos 可能因类型歧义放弃精确路由。
- 用
db.collection.findOne().region和typeof或$type检查真实类型 - 查询时保持类型完全一致：字符串就传字符串，数字就传数字，别依赖自动转换
- 聚合查询中尤其注意：在
$match阶段写{region: {$eq: "us"}}比{region: "us"}更明确，避免驱动层误处理
用了 $ne、$regex 等非路由友好操作符
某些查询操作符会让 mongos 彻底放弃分片路由推导，强制广播。这不是 bug，是设计限制：因为这些操作无法通过分片键哈希范围确定目标分片。
常见“路由杀手”包括：$ne、$not、$regex（非前缀匹配，如 /.*abc/）、$where、聚合中的 $lookup 或 $facet。哪怕分片键字段出现在条件里，只要裹着这些操作符，就失效。
- 前缀正则可用：
{name: {$regex: "^abc"}}能定向；但{name: {$regex: "abc"}}不能 -
$or是隐形陷阱：即使每个分支都含分片键，整个$or表达式也会触发广播 - 替代方案：拆成多次定向查询，或改用应用层过滤（适合小数据量场景）
聚合查询中分片键条件位置不对
聚合管道想走定向，分片键条件必须放在最外层 $match，且不能被逻辑操作符包裹。mongos 只解析第一层 $match 的静态条件来做路由决策。
例如：[{$match: {region: "cn", userId: "u123"}}, {$project: {...}}] 是安全的；但 [{$match: {$or: [{region: "cn"}, {region: "jp"}]}}, ...] 或 [{$facet: {...}}, {$match: {...}}] 都会绕过路由。
- 把分片键条件提到管道开头，并确保它独立、无嵌套逻辑
- 避免在
$facet、$lookup、$graphLookup后再加$match做分片键过滤 - 若必须用
$or，考虑用应用层分发多个定向查询，比单次广播更可控
分片键不是写进代码就一劳永逸的事——它要求每次查询都主动对齐，稍有偏差，性能就从毫秒级掉到秒级。最容易被忽略的是类型一致性，尤其是开发环境用 mock 数据、生产环境混入异构导入时，region 字段看着一样，底层类型却不同，这种问题往往要靠 explain + $type 组合才能揪出来。
