跨分片查询变慢是因为mongos将不带分片键条件的查询广播至所有分片，延迟随分片数线性增长且无法下推索引；必须强制在单文档操作、范围查询、聚合$match中显式指定分片键完整前缀，否则触发全量扫描。
为什么跨分片查询会变慢
当 mongos 收到一个不带分片键条件的查询时，它必须把请求发给所有分片（广播），等每个分片返回结果后再合并。这个过程延迟随分片数量线性增长——3个分片可能 50ms，12个分片就可能飙到 200ms+，且无法利用索引下推优化。
确保查询命中分片键的三个硬约束
不是“尽量带上分片键”，而是绝大多数读写路径必须强制包含它，否则就是设计缺陷：
- 单文档读写（
find()、updateOne()、deleteOne()）必须在filter中显式指定完整分片键字段（或前缀，若为复合键） - 范围查询（如
{ createdAt: { $gte: ... } }）若分片键不含createdAt，就必然广播；即使该字段有索引也无济于事 - 聚合管道中，
$match阶段必须出现在最前面，且条件需覆盖分片键；$lookup跨集合时，被查集合也得按同样规则设计，否则触发二次广播
复合分片键下容易忽略的“伪命中”陷阱
比如用了 { userId: 1, timestamp: 1 } 作分片键，以下查询看似合理，实则全量扫描：
db.orders.find({ timestamp: { $gt: ISODate("2026-09-01") } })
原因：MongoDB 只能利用复合索引/分片键的**最左前缀**。单独查 timestamp 不满足前缀匹配，路由层无法定位分片。
可行的替代方案包括：
- 改用哈希分片键（如
{ userId: "hashed" }），牺牲范围查询能力，换取写入均匀和点查确定性 - 加冗余字段，如把
userId拷贝进业务常用查询条件中（需应用层保证一致性） - 用
$or显式枚举已知userId值（仅适用于值集可控的场景）
如何快速识别正在广播的查询
别等线上报警，开发和压测阶段就要主动抓：
- 开启
mongos日志级别为 1：db.setLogLevel(1, "sharding")，搜索日志中是否出现scattered或broadcast - 用
explain("executionStats")查看executionStages.shards数组长度——大于 1 就说明没走对分片 - 监控
shardingStatistics中的scatterGatherQueries计数器，持续上升即存在隐患
真正难处理的不是“怎么查”，而是“怎么让所有业务代码默认就带分片键”——这需要在 DAO 层做参数校验、在 SDK 里封禁无分片键的 find 调用，而不是靠人写对。
