不能直接修改分片键，mongodb硬性禁止已写入数据的集合变更分片键；5.0+可用reshardcollection在线重分片，但需满足版本、唯一索引、writeconcern等严格条件；refinecollectionshardkey仅适用于空集合补全键；通用方案是重建集合+迁移数据。
分片键选错后能不能直接改
不能。MongoDB 对已写入数据的集合，禁止修改分片键 —— 无论是更改字段、调整顺序，还是从范围分片切到哈希分片，sh.shardCollection() 都会报 cannot change shard key pattern for existing collection。这不是权限或配置问题，是底层 chunk 路由逻辑决定的硬限制。
哪些情况允许“重新分片”而不是重建
从 MongoDB 5.0 开始，reshardCollection 命令支持真正意义上的分片键变更，但有严格前提：
- 集群版本 ≥ 5.0（8.0+ 支持
forceRedistribution和时间序列集合） - 目标分片键必须满足所有现有唯一索引的约束（例如：若已有
{email: 1}唯一索引，新键必须包含email字段） -
writeConcernMajorityJournalDefault必须为true - 操作期间禁用
createIndexes、drop、renameCollection等命令
执行示例：
db.adminCommand({ reshardCollection: "mydb.users", key: { "tenantId": 1, "userId": "hashed" } })注意：该操作会触发全量数据重分布，需预留足够磁盘空间（至少为集合大小 + 索引大小之和的两倍 ÷ 分片数）。
为什么很多人误以为 refineCollectionShardKey 能救场
refineCollectionShardKey 只对「已启用分片但尚未插入任何文档」的空集合有效。它不是改键，而是补全——比如原键是 {_id: 1}，可扩展为 {_id: 1, tenantId: 1}，但必须保持前缀一致且不能删字段。一旦集合里有哪怕一条文档，调用就直接失败，报错 collection must be empty。
重建集合是最通用也最可控的方案
当版本低于 5.0，或新键不满足唯一索引约束时，只能走重建路线：
- 新建集合，用
sh.shardCollection("mydb.users_new", {"tenantId": "hashed"})指定理想分片键（注意：字段必须已建索引，且不能是数组） - 用
mongodump --uri="mongodb://old-mongos/" --db=mydb --collection=users导出，再用mongorestore --uri="mongodb://new-mongos/" --drop导入 - 手动重建 TTL 索引、部分唯一索引等非分片键约束
- 应用层双写过渡期，最后用原子性
renameCollection切换（旧集合 rename 为 backup，新集合 rename 为原名）
最容易被忽略的是：分片键字段值在插入后不可修改，连 $set 都会失败，报 cannot modify shard key —— 所以迁移前务必确认业务逻辑是否依赖更新该字段。
