moveChunk仅支持单集合内单个chunk迁移，不支持跨集合原子操作；需应用层停写、按序迁移、校验恢复，且须预检chunk大小与分布。
moveChunk 只能操作单集合内的单个 chunk，跨集合不支持原子迁移
MongoDB 的 moveChunk 命令底层设计就是以「集合 + 分片键范围」为粒度的，它不感知、也不协调多个集合之间的状态。也就是说，哪怕两个集合共用同一分片键、数据高度关联（比如订单表和订单明细表），你也无法用一条命令让它们的对应 chunk 同时迁走——没有事务包装，没有两阶段提交，更没有跨集合锁。
常见错误现象：moveChunk 执行中途失败，只迁了一半数据；或者你手动连续执行两次 moveChunk，但中间发生了写入或平衡器介入，导致两个集合数据错位、关联断裂。
- 必须严格按集合逐个迁移，且每次只迁一个 chunk 范围（
find参数指定） - 若需逻辑一致性，得靠应用层控制：停写 → 按依赖顺序迁移 → 校验 → 恢复写入
- 别指望
sh.moveChunk()或db.runCommand({ moveChunk: ... })接收数组或通配符
为什么 MongoDB 不提供跨集合原子迁移能力
这不是遗漏，而是架构取舍。分片元数据（config.chunks）是按集合隔离存储的，每个 chunk 记录只包含 ns（命名空间）、min/max（分片键范围）、shard（归属分片）字段，没有跨集合引用机制。迁移流程本身由源分片发起、目标分片确认、config server 更新三步组成，全程无分布式事务支撑。
性能与兼容性影响：加跨集合协调会显著拖慢 balancer 速度，也和 WiredTiger 引擎的本地事务边界冲突。从 3.2 到 8.0，所有稳定版本都维持这一设计，官方文档从未承诺过此类能力。
- 试图用
directshardoperations角色绕过限制？风险极高——可能破坏 config server 元数据一致性，且该角色仅限 MongoDB 支持人员在指导下使用 - 不要修改
config.chunks集合手工“拼接”记录，WiredTiger 不保证其原子性，后续moveChunk会校验失败
替代方案：如何安全实现“类原子”的多集合迁移
真有强一致性要求（比如金融类分库分表迁移），只能靠外部协调+窗口控制。核心不是让 MongoDB 做原子操作，而是让它没机会做错事。
- 禁用 balancer：
sh.stopBalancer()，并确认sh.getBalancerState()返回false - 停写所有相关集合：不只是应用停写，还要检查是否有后台 job、聚合管道写入、$out 阶段等隐式写入源
- 按依赖顺序执行
moveChunk：例如先迁orders，再迁order_items，两者用相同find条件（如{ order_id: { $gte: 100000, $lt: 200000 } }） - 迁移后立即校验：用
db.collection.stats().sharded和db.collection.getShardDistribution()确认 chunk 分布，再抽样比对关键关联字段
注意：即使这样做了，也不能叫“原子”，只是把不一致窗口压缩到秒级，并靠人工兜底。真正的原子性，得上应用层 Saga 模式或双写+对账。
容易被忽略的硬限制：chunk 大小和迁移并发瓶颈
很多人以为只要停写+顺序执行就稳了，结果卡在 chunk 搬不动。根本原因常被忽视：默认 chunk 最大 64MB，但如果你的集合启用了 shardCollection 时没设 initialSplit，或分片键选择不当，会导致单个 chunk 远超该值——moveChunk 会直接拒绝执行，并报错 ChunkTooBig。
- 检查 chunk 大小：
db.getSiblingDB("config").chunks.find({ ns: "mydb.mycoll" }).sort({ min: 1 }).limit(5).forEach(printjson)，看size字段 - 拆大 chunk 必须用
splitChunk，且只能在 chunk 当前所在分片上执行，不能远程调用 - 迁移并发受
secondaryThrottle控制：设为true（3.2 默认）会等从节点写入，延迟高但安全；设为false（3.4+ 默认）快但风险略升
真正麻烦的是，这些限制不会在迁移前主动提示，而是在 moveChunk 执行中突然失败——所以迁移前务必跑一遍 chunk 分布和大小扫描，别只盯着集合名和分片键。
