MongoDB分片键变更本质是数据拓扑重构，必须逐chunk重划范围、搬运文档，无法仅更新元数据；reshardCollection会施加2秒写锁并强制双键查询，阻塞业务且要求应用适配；空集合可用refineCollectionShardKey，否则须停写重建或双写灰度迁移。
修改MongoDB分片键索引会直接触发底层chunk路由元数据重计算，而MongoDB不允许在运行时动态重映射已有文档的物理位置，因此系统必须暂停写入并逐块迁移数据以保证一致性。
分片键索引变更的本质是数据拓扑重构
分片键不是普通索引，它绑定着每个文档的shard key value→chunk range→物理分片的三层映射关系。当你执行reshardCollection或尝试用sh.shardCollection覆盖已有键时，MongoDB必须为每一块现存chunk重新划分边界、生成新范围、搬运文档——这个过程无法跳过，也不能仅靠元数据更新完成。
这一步操作起来很简单，直接调用命令就行，但背后没有“轻量级切换”这回事。
阻塞根源：写锁与双键查询约束并存
reshardCollection会在每个chunk迁移前施加最长【2秒写锁】，期间所有对该chunk的写操作（insertOne、updateOne、findAndModify等）都会排队等待。这不是全局锁，但对落在该chunk上的业务请求就是实打实的阻塞。
更关键的是，迁移过程中所有查询必须同时包含旧分片键字段和新分片键字段，例如原键是{tenantId: 1}、新键是{tenantId: 1, _id: "hashed"}，那么find({tenantId: "abc"})会直接报错Cannot target a shard key that is not present in the query，而find({tenantId: "abc", _id: {$exists: true}})才能通过。
应用若未提前适配双键条件，查询将大面积失败。
为什么不能跳过锁和双键校验
第一步：MongoDB必须确保迁移中任意时刻的读写都可精准路由到正确chunk。如果允许只按新键查，旧键范围内的文档尚未全部搬完，就会漏读；如果允许只按旧键查，新键范围已生效的chunk又会无法命中。
第二步：写锁是防止chunk分裂/合并过程中出现文档状态不一致的唯一手段。没有它，一个正在被拆分的chunk可能同时接受写入和迁移，导致部分文档丢失或重复。
第三步：索引本身不参与路由决策——分片键字段是否建索引，只影响查询性能；但分片键定义一旦写入config数据库，就冻结为集群级契约，任何绕过它的操作都会破坏sharding metadata的一致性。
替代路径只有重建集合
方法一：停写旧集合→mongodump导出→新建带目标分片键的集合→mongorestore --drop导入→手动重建TTL/唯一索引→切流。
方法二：应用双写→灰度迁移→校验数据一致性→停旧写→追平最后增量→切流。
注意：refineCollectionShardKey仅适用于【已启用分片但从未插入任何文档】的空集合，对已有数据完全无效。
