reshardcollection会触发单次最长2秒的写锁，导致相关写请求阻塞并引发延迟突刺；查询须同时包含新旧分片键字段，否则报错；需预留至少1.2倍集合storagesize的磁盘空间，并在完成后手动清理旧索引及更新应用逻辑。
reshardCollection 会触发写锁，不是“无感”操作
reshardCollection 不是后台静默迁移，它会在每个 chunk 迁移前对目标 chunk 加写锁，单次最长约 2 秒。这不是全局锁，但落在该 chunk 上的所有写操作（insertOne、updateOne、deleteOne、findAndModify）都会被阻塞。
常见现象包括：
- 应用日志中集中出现
WriteConflict或MaxTimeMSExpired - 监控图表上
write latency出现周期性尖峰，时间戳与resharding日志对齐 - 依赖
session.startTransaction()的事务因锁等待超时而失败
实操建议：
- 确认业务能容忍单次 ≤2 秒的写入暂停；若不能，必须安排在低峰期执行，并配合应用层重试逻辑
- 避免在 resharding 期间执行大事务或长耗时更新，否则容易被锁住并拖慢整个迁移进度
-
maxTimeMS无法绕过锁——这是 MongoDB 内部机制，超时参数只作用于查询阶段，不解除写锁
查询必须同时命中新旧分片键字段
resharding 过程中，MongoDB 要求所有对该集合的读写操作都必须包含当前分片键和新分片键的字段，否则直接报错：Cannot target a shard key that is not present in the query。
典型错误示例：
-
find({ name: "zhangsan" })→ ❌ 只含旧键name，报错 -
updateOne({ name: "zhangsan" }, { $set: { status: "active" } })→ ❌ 不满足双键条件 -
find({ name: "zhangsan", _id: ObjectId("...") })→ ✅ 同时含旧键name和新键_id
注意点：
- 即使没显式用到新键字段，也必须传进去（可用
{$exists: true}或合理范围值兜底） - 聚合管道中
$match阶段同样受约束，不满足双键则阶段被拒绝执行 - 索引必须已存在且覆盖新旧键组合，否则查询性能会断崖式下跌
磁盘空间不足会导致 resharding 中途失败并回滚
reshardCollection 不是原地修改，而是先在新分片上构建副本数据，再逐步切换路由。因此需要额外磁盘空间：至少为原集合 storageSize 的 1.2 倍。例如集合占 1TB，空闲空间必须 ≥1.2TB。
容易踩的坑：
- 误以为“只是改路由”，忽略临时副本占用；实际每个参与迁移的
shard都要写一份新格式数据 - 未按公式计算：可用空间需满足
((collection_size + index_size) * 2) / shard_count，而非简单看总空间 - Atlas 用户常忽略 I/O 容量限制——resharding 期间 I/O 必须低于
50%，否则迁移变慢甚至卡死
MongoDB 8.0+ 的 forceRedistribution 是另一类影响
从 MongoDB 8.0 开始，reshardCollection 支持 forceRedistribution: true，用于相同分片键下的数据重分布（如加新分片、删分片、回收磁盘空间）。但它仍会重写所有未排干分片的数据，且默认使用 numInitialChunks: 90（哈希分片时该参数被忽略）。
关键差异：
- 不再要求新旧键不同，但依然触发写锁、占用磁盘、阻塞禁用命令（如
createIndexes、drop） - 如果集合启用了 Atlas Search，resharding 完成后搜索索引会变为
Orphaned，必须手动重建 - 时间序列集合仅支持
MongoDB 8.0.10+，且所有分片必须升级到该版本才能执行
真正容易被忽略的是：resharding 不是“一次配置就完事”的操作——它对应用逻辑、索引策略、监控告警、备份窗口都有连锁影响，尤其当集群承载核心交易或实时分析时，锁、查询兼容性、磁盘预估这三点必须逐项验证，缺一不可。
