是，分片后查询变慢大概率因广播查询；不带分片键的find()会向所有分片发送请求，导致N次扫描+网络聚合，响应时间取决于最慢分片，且explain中可见多分片totalDocsExamined非零。
分片后查询变慢，是不是发起了广播查询
大概率是。分片集群里没带分片键的查询会路由到所有分片，也就是广播查询——它不慢在单次扫描，而在所有分片并发执行+结果合并的开销。你看到 executionStats.nReturned 很小但 executionStats.totalDocsExamined 累加起来巨大，就是典型信号。
检查方法很简单：用 explain("executionStats") 跑一次你的慢查询，看返回里有没有 "executionStages": { "stage": "SHARD_MERGE" }；再翻 shards 字段，如果列出多个分片且每个都报告了 totalDocsExamined，基本坐实广播。
- 只查单一分片的查询，
shards数组长度应为 1 - 如果查询条件含分片键（等值匹配），且分片键字段在索引最左前缀位置，MongoDB 才能精准路由
- 范围查询（如
{ shardKey: { $gt: 100 } }）也可能跨分片，但比无分片键的全广播好得多
索引里没包含分片键，等于白建
分片集群中，索引必须“覆盖”分片键，否则即使有索引，查询仍可能广播。不是说“有索引就快”，而是“索引 + 分片键组合能定向到分片”。例如分片键是 { region: 1, userId: 1 }，那有效索引至少得以这两个字段开头：
db.orders.createIndex({ region: 1, userId: 1, status: 1 }) // ✅ 可用于 { region: "US", userId: 123 } 查询
db.orders.createIndex({ status: 1, region: 1 }) // ❌ region 不在最左，无法支持分片路由
- 复合索引中，分片键字段必须是前缀（顺序严格），不能跳过或放中间
- 哈希分片键（如
{ _id: "hashed" }）也一样：索引需包含_id才能避免广播，且不能只建{ createdAt: 1 }这类无关索引 -
db.collection.getIndexes()查出来的索引，逐个核对是否含分片键前缀——很多线上库就卡在这一步
分片键本身被哈希了，范围查询就容易踩坑
哈希分片让数据分布均匀，但代价是牺牲了范围查询能力。如果你常用 { createdAt: { $gte: ... } } 这类查询，而分片键又是哈希的（比如 { userId: "hashed" }），那这个查询必然广播——因为哈希值和时间毫无顺序关系，MongoDB 无法判断哪些分片存了“最近的数据”。
- 哈希分片下，只有等值查询（
{ userId: 123 }）能精准路由；所有范围、排序、正则等操作都会退化为广播 - 别指望
sort({ createdAt: -1 })能走索引加速：即使createdAt有索引，分片层已失去路由依据，各分片各自排序再合并，性能雪崩 - 真要支持时间范围查询，要么改用范围分片（需业务接受数据倾斜风险），要么在应用层做分片感知（比如按月分库+路由规则）
聚合管道里漏了分片键，整个 stage 就失效
聚合查询更容易掉进广播陷阱。哪怕 $match 阶段写了分片键，只要后续 $lookup、$unwind 或 $group 操作脱离了分片上下文，整个 pipeline 就可能被拉到 mongos 合并，变成单点瓶颈。
- 确保第一个
$match必须含分片键等值条件，且不能被$or、$in（含空数组）、$expr等破坏可路由性 -
$lookup如果关联的是非分片集合，或目标集合分片键未出现在 localField/foreignField 中，也会强制广播 - 用
explain("executionStats")看聚合输出里的stages，重点找"stage": "SHARDING_FILTER"是否出现在最外层——没有就说明没切分
真正难处理的不是“要不要加索引”，而是索引建在哪、怎么和分片键咬合。很多人补了索引却没补对位置，结果性能纹丝不动。分片环境下的索引，本质是路由指令，不是单纯加速扫描的工具。
