MongoDB事务不支持跨分片原子性，分片迁移由balancer控制、与事务无关，无法在事务中执行sh.moveChunk()等管理命令；其本质是跨节点、多进程的元数据与数据重分布过程，不受事务session管理。
MongoDB 事务本身不支持跨分片原子性，所以“在事务中做分片迁移”这个动作根本不存在。 分片迁移是集群元数据和数据块（chunk）的重新分布过程，由 balancer 控制，与应用层事务无关。你不能把 sh.moveChunk() 或 sh.splitAt() 包进一个 session.startTransaction() 里执行。
为什么事务无法覆盖分片迁移操作
分片迁移涉及 config server 更新路由表、源 shard 写入迁移日志、目标 shard 拉取并应用数据、最后清理旧 chunk —— 这些步骤跨多个进程、多个节点，且部分操作（如 config server 写入）不走普通写协议，也不受事务 session 管理。MongoDB 的分布式事务只支持单文档多操作（multi-document transactions），且仅限于副本集内；一旦进入分片集群，事务自动降级为“尽力而为”，不会阻塞或协调跨 shard 的状态变更。
- 事务写入只能发生在单个 shard 上（即该集合已按某字段分片，且你查询/更新时能路由到唯一 shard）
-
sh.moveChunk()是管理命令，运行在mongos，不走 oplog 复制路径，也不参与事务日志链 - 迁移过程中，chunk 可能处于“正在迁移”（
chunk.migrationState=moving）状态，此时对该 chunk 范围的读写仍被允许，但由 mongos 动态路由，不是事务保证的中间态
实际迁移中如何应对事务一致性风险
真正需要关心的不是“事务包住迁移”，而是迁移期间业务写入是否导致数据不一致或丢失。关键点在于：迁移本身不中断写，但写入可能落在迁移中的 chunk 上，而 mongos 会自动处理路由转发 —— 这个机制可靠，但有边界条件。
- 确保迁移前已禁用 balancer：
sh.stopBalancer()，否则自动迁移可能与你手动操作冲突 - 避免在迁移进行时修改分片键值（比如 update 某文档的 shard key 字段），这会导致文档被重路由，可能触发 chunk 拆分或迁移，造成不可预测行为
- 如果业务依赖强一致读（例如刚写完立刻查），不要在迁移 chunk 的分片上做
readConcern: "majority"+writeConcern: "majority"组合读写，因为迁移中该 shard 的 majority 可能临时变化 - 对关键业务表，可在迁移前用
sh.disableSharding("db.collection")临时关闭自动分片（仅限 MongoDB ≥ 5.0），防止意外 split
双写场景下事务与迁移共存的坑
如果你正用双写方案（应用同时写源/目标集群）做灰度迁移，又恰好在源集群上执行分片迁移，要注意 oplog 和事务时间线错位问题。
- 双写产生的写操作会写入源集群 oplog，但迁移过程本身不产生 oplog 条目，
mongosync不会感知 chunk 移动，只同步文档级变更 - 若迁移中发生 chunk 拆分，新 chunk 的初始范围可能没被
mongosync的 oplog tailing 捕获，导致后续写入漏同步 - 目标集群的 shard key 必须与源完全一致，否则同一事务内写入的多文档，在两边可能落到不同 shard，破坏事务语义（哪怕源端事务成功，目标端数据已散落）
- 不要在双写期间调用
sh.reshardCollection()—— 它会重建整个集合的 chunk 分布，而mongosync无法重放这种元数据级变更
真正难处理的不是迁移动作本身，而是迁移窗口期内，应用逻辑、balancer 状态、oplog 位点、以及目标集群分片策略四者的耦合。任何一个环节配置偏差，都会让“看起来成功”的迁移在几天后暴露数据倾斜或查询失败。尤其注意 sh.getBalancerState() 返回 true 并不意味着 balancer 当前没在干活——它只表示开关开着，实际任务队列可能还有积压。
