shard key必须有严格匹配的索引，否则mongos广播查询导致全分片COLLSCAN；索引字段顺序、方向须完全一致，不可稀疏或唯一（除非_id），哈希分片键需显式hashed索引。

shard key没索引会导致全分片扫描

mongos 没法靠裸字段值定位数据，必须依赖索引把 shard key 值映射到具体 chunk 和分片。没索引时，它只能向所有分片广播查询或写入——看起来像“扫描全表”，实际是每个分片都执行 COLLSCAN，explain() 里会看到大量 "stage": "COLLSCAN" 和 "stage": "SHARD_MERGE"。

shard key索引的硬性要求有哪些

不是随便建个索引就行，必须满足：

• 索引字段顺序必须严格匹配 shard key 的前缀（比如 shard key 是 {region: 1, userId: 1}，那 {region: 1} 或 {region: 1, userId: 1, status: 1} 可用，但 {userId: 1, region: 1} 不行）
• 方向必须一致（{a: 1, b: -1} 作 shard key，索引也得是 {a: 1, b: -1}；{a: 1, b: 1} 不被接受）
• 不能是稀疏索引（sparse: true）、不能是唯一索引（除非是 _id 或明确用于强制 shard key 全局唯一）
• 哈希分片键（{field: "hashed"}）允许建对应哈希索引，且从 MongoDB 6.0.12 起可删除

如何快速确认缺失索引

别凭感觉猜，三步直接验证：

• 连任意 mongos，运行 sh.status()，确认目标集合已分片且显示了 shard key
• 连到任一分片的主节点（不是 mongos），执行 db.getCollection('your_collection').getIndexes()
• 检查输出中是否存在以 shard key 字段开头、类型为 1 或 -1 的索引；常见漏掉的情况包括：只建了复合索引但顺序/方向不匹配，或误以为 _id 索引能替代

创建索引的时机和陷阱

空集合和非空集合处理方式完全不同：

• 集合为空时，sh.shardCollection() 会自动在 shard key 上建索引（如果尚不存在）
• 集合已有数据，必须先手动建好索引，再调用 sh.shardCollection()，否则报错 "cannot shard collection without an index on the shard key"
• sh.reshardCollection() 会自动重建新 shard key 所需索引，无需提前干预
• 唯一索引一旦绑定 shard key，就不能删或 hide——除非是哈希分片键且 MongoDB ≥ 6.0.12

最常被忽略的是方向一致性：哪怕字段名和顺序都对，-1 和 1 差一个符号，索引就不可用。查 getIndexes() 输出时，务必盯住 key 字段里的数值符号。