MongoDB 5.0起支持安全可控的重新分片（reshardCollection），非热切换，而是原子性迁移：建新结构、逐块拷贝校验、替换元数据；写入阻塞约2秒，查询可继续；需满足磁盘空间、CPU负载、索引及命令限制等前提。
不能“动态调整”分片键——但可以从 MongoDB 5.0 起安全、可控地重新分片（reshard），前提是提前规划好审计节奏和变更窗口。
reshardCollection 命令实际能做什么
它不是热切换分片键，而是启动一个原子性迁移流程：MongoDB 创建新分片结构（含新片键索引）、逐块拷贝+校验+删除旧块，最终替换元数据。整个过程对应用是写入阻塞约 2 秒（非全停机），但查询可继续（可能跨新旧结构路由）。
-
reshardCollection必须指定完整命名空间，如"user_center.users"，不能只写集合名 - 新片键必须已建索引，且满足唯一约束（若原集合有
unique: true索引，新片键组合也得保证全局唯一） - 执行期间禁止运行
createIndex、drop、renameCollection等 9 类命令，否则操作直接失败 - 不支持时间序列集合（TS collections）——直到 MongoDB 8.0.10 才放开，且所有分片必须升到该版本
为什么必须定期审计，而不是等出问题再改
分片键一旦选定，数据分布就固化在 chunk 分配逻辑里。等出现 sh.status() 中某分片 chunk 数超其他分片 3 倍、或 balancer 连续数小时无法收敛，说明倾斜已深入底层，reshard 成本远高于早期干预。
- 审计重点不是“当前是否均衡”，而是“未来 3 个月写入模式是否仍匹配片键”：比如按
created_at范围分片，但业务突然增加按region的高频聚合，就得考虑复合键 - 每季度用
db.<collection>.stats({scale: 1024*1024})</collection>查各分片数据量，比值 > 1.5 就该预警 - 监控
moveChunk日志频率：如果平衡器每小时触发 > 5 次迁移，说明 chunk 大小（默认 64MB）或片键粒度不合适，优先调sh.setBalancerState({ chunkSizeMB: 128 })而非立刻 reshare
reshard 前必须验证的三件事
跳过任一验证，大概率导致迁移中断或数据不一致。
- 磁盘空间：目标分片上可用空间 ≥ 集合大小 × 1.2（MongoDB 5.0–7.x）或 × 2（MongoDB 8.0+，因 forceRedistribution 默认启用）
- CPU 负载：所有分片 mongod 进程 CPU 使用率持续
- 应用兼容性：查询语句必须同时兼容新旧片键——例如旧键是
{user_id: 1}，新键是{region: 1, user_id: "hashed"}，则查询需补region条件，否则路由失效
8.0 的 forceRedistribution 是双刃剑
MongoDB 8.0+ 允许用 forceRedistribution: true 对同一片键重新分片（比如加了新分片节点后强制重分配），但它会强制重写所有未 drain 的分片，IO 压力极大。
- 默认
numInitialChunks: 90，若集群有 200 个分片，必须显式设为numInitialChunks: 2000，否则 chunk 数不足，新分片长期空转 - 该参数不影响已有数据分布，只控制初始切分粒度；真正决定负载是否均匀的，仍是片键本身的设计质量
- 即使用了
forceRedistribution，仍需手动重建 MongoDB Search 索引——reshard 完成后db.adminCommand({rebuildSearchIndexes: "db.coll"})不会自动执行
真正难的从来不是执行 reshardCollection，而是判断“现在改是否比半年后改更省事”。片键设计缺陷会在数据量每翻一倍时，把运维成本放大三倍——所以审计不是例行公事，是给下次扩容留出确定性窗口。
