mongodb 不允许修改已分片集合的分片键，这是硬性限制；唯一可行方案是重建集合并迁移数据，包括新建分片集合、导出导入数据、手动重建索引及处理增量同步。
修改 MongoDB 已存在集合的分片键根本不可行
MongoDB 不允许对已启用分片的集合更改分片键（shard key），也不支持对已有数据的集合新增分片键。这是硬性限制，不是配置或权限问题 —— 一旦执行 sh.enableSharding() 或 sh.shardCollection()，分片键就冻结了。
常见错误现象包括：cannot change shard key pattern for existing collection、shard key cannot be changed 这类报错，通常出现在尝试用 sh.shardCollection("db.coll", {newKey: 1}) 覆盖已有分片键时。
原因很直接：分片键决定了文档在分片集群中的物理位置（chunk 分布）和路由逻辑；改键等于重定义整个数据拓扑，服务无法安全推导旧 chunk 与新键的映射关系。
替代方案：重建集合 + 迁移数据
唯一可行路径是新建一个按目标分片键分片的集合，把旧数据导出再导入。这不是“修改”，而是“替换”。
- 先创建新集合，用
sh.shardCollection("db.new_coll", {"targetField": "hashed"})指定理想分片键（注意：字段必须已建索引，且不能是数组） - 用
mongodump+mongorestore --drop迁移，或在应用层双写+切换流量 - 若原集合有 TTL 索引、部分唯一索引、非分片键上的唯一约束，这些需手动在新集合上重建
- 迁移期间旧集合仍可读写，但新集合上线前无法自动同步增量 —— 必须自行处理最后窗口期的数据追平
Refine Shard Key 特性仅适用于未分片集合
refineCollectionShardKey 是 MongoDB 4.4+ 引入的操作，但它**不用于修改已有分片键**，而是为“已启用分片但尚未插入任何数据”的空集合，补充更细粒度的分片键字段（例如从 {_id: 1} 扩展为 {_id: 1, tenantId: 1}）。
使用前提非常严格：
- 集合必须已执行过
sh.enableSharding()，但 从未插入过文档 - 新键必须是原键的**超集**（即包含原键所有字段，且顺序一致），不能变更类型或删除字段
- 操作后仍需调用
sh.shardCollection()指定完整键，否则不会真正分片 - 该命令不触发 chunk 拆分或迁移，只更新元数据 —— 所以它快，但也毫无意义，除非你卡在“刚启分片、还没写数据”的极窄窗口
容易被忽略的关键约束
即使走重建路线，也常踩这些坑：
- 分片键字段值在插入后不可修改 —— 即使是
$set也会失败，报错cannot modify shard key - 哈希分片键（如
{"uid": "hashed"}）要求字段必须是单值，不能是数组或嵌套对象，否则插入直接报错 - 如果原集合用了
_id作为分片键，而新键不含_id，那 ObjectId 自动生成逻辑可能引发 chunk 倾斜（因为 ObjectId 时间戳部分导致写入集中到一个分片） -
refineCollectionShardKey的响应不抛异常不代表成功：必须检查返回的ok: 1和collectionVersion是否递增，否则可能是静默忽略
真要换分片键，别寄希望于在线调整。停写、备份、重建、校验、切流 —— 每一步都得自己兜底。分片键选型，永远比事后补救重要得多。
