查询速度取决于精准路由到单个分片，而非负载均衡；关键在于正确指定分片键、建立匹配索引，并在查询中包含分片键字段。
分片集群本身不靠“配置负载均衡”来优化查询速度——mongos 路由和分片键设计才是关键。所谓“负载均衡”在 MongoDB 里实际指数据块（chunk）在分片间的分布平衡，它影响的是写入吞吐与存储压力，而非单次查询响应时间。查询快不快，取决于能不能被精准路由到单个分片。
sh.shardCollection 必须指定分片键，否则查询变全量扫描
没启用分片或未正确指定分片键时，mongos 无法判断目标分片，所有查询都会广播到全部分片（scatter-gather），延迟直接翻倍甚至更高。
- 错误做法：
sh.shardCollection("mydb.users", {})—— 空对象不生效，集合仍为非分片状态 - 正确做法：
sh.shardCollection("mydb.users", {"user_id": "hashed"})或{"region": 1, "created_at": -1} - 验证是否生效：
sh.status()查看该集合下是否有chunks分布，且shard列显示多个分片名 - Laravel-mongodb 用户注意：Schema 中的
shardKey只是声明，最终仍需在 mongos shell 执行sh.shardCollection才生效
sh.enableSharding 后必须建索引，否则分片键字段查得慢
分片键字段默认不会自动建索引。如果用 user_id 做哈希分片但没建 {user_id: "hashed"} 索引，$match 过滤会退化为全 chunk 扫描，哪怕只路由到一个分片。
- 执行前确认：
db.users.getIndexes()检查是否存在对应索引 - 补建索引：
db.users.createIndex({"user_id": "hashed"})（类型必须与分片键一致） - 复合分片键同理：
db.orders.createIndex({"shop_id": 1, "order_time": -1}) - 注意：哈希索引不支持范围查询，
{"user_id": {"$gt": 100}}会失去路由精度
sh.isBalancerRunning() 不代表查询更快，只是块在迁移
负载均衡器（balancer）运行中，说明系统正在把 chunk 从重分片往轻分片搬——这是后台维护动作，期间反而可能拖慢写入、增加网络开销，对读查询无加速作用。
- 查状态用：
sh.isBalancerRunning()（返回 true/false），不是sh.getBalancerState()（只返回启用开关） - 生产环境建议设均衡窗口：
db.settings.updateOne({"_id": "balancer"}, {$set: {activeWindow: {start: "02:00", stop: "05:00"}}}) - 块大小别乱调：
chunkSize默认 64MB，调到 32MB 会增倍元数据压力，仅在写入热点明显时谨慎下调 - 真正影响查询速度的是
sh.status()里各分片的size是否接近——差值超过 30% 才值得干预
最容易被忽略的一点：查询语句里没带分片键字段，mongos 就没法路由。哪怕分片键是 {uid: 1, ts: -1}，你只写 {ts: {"$gt": ...}}，照样扫全分片。路由精度永远优先于 balancer 是否运行。
