reshardCollection 和 refineCollectionShardKey 均不满足业务无感的在线分片键变更要求：前者迁移前强制加写锁2秒导致写入拒绝，后者为实验性功能且不自动迁移数据、限制严苛、路由易不一致。
不能真正在线修改——reshardCollection 会阻塞写入，refineCollectionShardKey 是实验性功能且不自动迁移数据，两者都不满足“业务无感”的在线要求。
为什么 reshardCollection 不是在线操作
它在每个 chunk 迁移前强制加写锁约 2 秒，期间所有落在该 chunk 上的 insert、update、delete 请求直接被拒绝，报错：Command not supported on sharded collection while resharding。
常见误判点：
- 不是偶发延迟，是设计级锁，
--noIndexBuilds或调大maxTimeMS完全无效 - 必须通过
mongos执行；直连分片节点会报：not authorized on admin to execute command reshardCollection - 并发发起多个
reshardCollection请求时，后续请求立即失败，不排队、不等待
refineCollectionShardKey 为什么不能用于生产细化场景
它名义上支持“添加后缀字段”，但实际限制极严，导致几乎无法落地：
- 新字段必须已在所有文档中存在，且值非
null、非缺失（不能是可选字段） - 新字段不能是数组（否则报：
Cannot refine shard key with array field） - 集合不能有预拆分 chunk（否则报：
Refining shard key requires all chunks to be owned by the same shard） - 执行后不会迁移现有数据——旧 chunk 仍按原键路由，新键只影响后续插入和查询，极易引发路由不一致
-
sh.status()输出中shard key字段仍显示旧键，新键仅藏在refinedKey子字段里，监控脚本若只读主字段会误判
真正可行的生产级分片键变更路径
绕过两个命令，用组合操作实现等效效果，全程无停机但需周密准备：
- 先用
sh.splitAt()和sh.moveChunk()将每个 chunk 拆到最小粒度（例如按当前region值切分），确保 chunk 边界对齐未来新键前缀 - 创建新集合，设好目标分片键（如
{region: 1, userId: 1}），并用preSplit: true预拆分好范围 - 用
mongodump+mongorestore --maintainInsertionOrder --drop迁移数据；注意加--maintainInsertionOrder避免并发写入打乱 chunk 分布 - 切换应用写入新集合，再通过 change stream 或双写比对做最终一致性校验
关键代价：迁移期间需预留双倍磁盘空间；mongorestore 会重写 _id 索引——若原集合用了自定义 _id 类型，必须提前验证兼容性。
最容易被忽略的一点：即使你成功调用了 refineCollectionShardKey，后续对新字段做 $lookup 聚合时，mongos 可能仍按旧键路由，部分分片会被跳过，问题静默发生，排查成本极高。
