mongodb分片键一旦设定不可修改，这是硬性限制；唯一可行方案是重建集合并迁移数据，包括新建分片集合、导出导入数据、手动重建索引及处理增量同步。
分片键不可改，但查询压力能缓解
分片键一旦设定就无法修改，这是 MongoDB 的硬限制。你不能重设 shardcollection 的键，也不能对已有分片集合执行 sh.rebalanceCollection() 来“换键”。但很多团队误以为“键选错了就只能重建集群”，其实只要查询模式固定、数据分布尚可，完全可以通过局部索引 + 查询重构来绕过瓶颈。
为什么辅助索引在分片集群里容易失效
常见错误是直接在 mongos 上建个新索引就以为万事大吉。但分片集群中每个 shard 是独立 mongod 实例，mongos 只负责下发命令——某个 shard 若因负载高、磁盘满或网络抖动没执行成功，这个索引就只存在于部分节点上。后续对该 shard 的查询会退化为 collection scan，且 explain("executionStats") 里根本看不出异常，因为 mongos 汇总的是“所有 shard 都返回了结果”，不校验是否真用了索引。
- 必须逐个登录每个 shard 的 primary 节点，运行
db.col.getIndexes()确认索引存在、字段顺序一致 - 复合索引中，分片键字段必须是前导字段，否则无法下推过滤。例如分片键是
{ tenant_id: 1, created_at: -1 }，那么{ status: 1, created_at: -1 }这类索引对{ tenant_id: "x", status: "done" }查询完全无效 - 真正可用的辅助索引得写成
{ tenant_id: 1, created_at: -1, status: 1 }或{ tenant_id: 1, status: 1, created_at: -1 }——分片键字段必须打头
哪些查询能靠辅助索引“救回来”
不是所有查询都能补救。核心看两点：是否含分片键字段、是否满足索引覆盖。比如日志表用 { _id: "hashed" } 分片，但业务高频查 { user_id: "u123", event_type: "click" }，这时建 { user_id: 1, event_type: 1 } 没用，因为不含分片键；但建 { _id: "hashed", user_id: 1, event_type: 1 } 也不行，哈希字段不能做范围查询，且 _id 值业务层不可控。
- 能救的情况：查询条件中明确包含分片键字段（哪怕只是等值），例如
{ tenant_id: "abc", status: "pending" }，且分片键是tenant_id或其前缀 - 不能救的情况：纯非分片键字段查询（如只查
status）、时间范围查询但分片键不含时间字段、正则匹配或 $text 查询 - 建索引时加
{ background: true }，避免阻塞写入；但注意 4.2+ 版本中 background 索引仍可能锁住 chunk 迁移，高峰期慎操作
聚合管道里索引到底有没有被用上
很多人建完索引发现聚合还是慢，问题常出在 $match 位置。mongos 只有在聚合第一阶段是 $match、且该条件含分片键时，才会把过滤下推到各 shard 执行。一旦前面有 $lookup、中间夹了 $unwind、或者 $match 写在第二步，整个 pipeline 就变成全量拉取 → mongos 内存合并 → OOM 风险陡增。
- 正确写法：
[ { $match: { tenant_id: "abc", created_at: { $gte: ISODate("2025-01-01") } } }, { $group: ... } ] - 错误写法：
[ { $lookup: ... }, { $match: { status: "done" } }, ... ]—— 此时$match完全无法下推 - 验证方式：在 mongos 上执行
db.col.explain("executionStats").aggregate([...])，重点看shards下每个分片的nReturned是否远小于totalDocsExamined；若两者接近，说明没走索引下推
真正难补救的，是那种分片键基数极低（比如全集合 tenant_id 只有 3 个值）又长期没发现的情况——此时 chunk 根本分不开，均衡器也无能为力。这种场景下，索引再全也没法避免跨分片广播，只能停写、导出、重建分片集合。补救的前提，是数据还“够散”。
