跨集合移动数据必须在单个会话中完成，所有CRUD操作需显式传入session参数，否则事务失效；推荐先删后插、分页处理、确保集合存在与权限完备，并调用endSession()防止泄漏。
事务中跨集合移动数据必须用单个会话执行
MongoDB 事务不支持跨会话操作，所有 insertOne、deleteOne、updateOne 等操作必须在同一个 session 内发起，否则事务无法感知后续操作，原子性直接失效。常见错误是把“先查再删再插”拆成多个独立命令，或者误以为不同 collection.insert() 调用天然属于同一事务——其实它们默认走的是无会话的普通写入。
正确做法是显式启动会话，并将全部操作链式绑定到该会话：
const session = client.startSession();
try {
await session.withTransaction(async () => {
await db.collection('orders').deleteOne({ _id: orderId }, { session });
await db.collection('archived_orders').insertOne({ ...doc, archived_at: new Date() }, { session });
});
} finally {
await session.endSession();
}
-
session必须传给每个 CRUD 方法，漏传即脱离事务上下文 - 不能在事务块外对同一文档做读写（例如先
findOne再进事务），否则可能读到过期快照或引发写冲突 - 跨集合操作要求所有集合在同一分片键下（若使用分片集群），否则事务会报错
TransactionNotSupportedOnShardedCluster
删除与插入必须共用同一 session 且顺序可控
事务内操作顺序影响锁持有时间和并发表现，但不影响原子性结果——只要都在 withTransaction 块里，失败则全部回滚。不过实际中常因顺序不当导致意外阻塞或死锁。
比如先插入再删除，若目标文档已存在（如归档表有唯一索引），插入会失败并中断事务；而先删后插更符合“移动”语义，也避免冗余数据残留。
- 推荐顺序：先
deleteOne/deleteMany，再insertOne/insertMany - 若需保留原始字段结构，不要手动拼接对象，用
doc._id等原生字段，避免丢失 ObjectId 或日期类型 - 注意
insertOne不会自动覆盖同_id文档，若归档表允许重复归档，需确认是否要加upsert: true（但此时已不属于纯“移动”，而是“迁移+更新”）
事务超时和长时间运行会触发自动中止
MongoDB 默认事务最大运行时间是 60 秒（transactionLifetimeLimitSeconds），跨集合移动大量数据时极易超时。一旦超时，事务自动 abort，已执行的删除不会回滚——因为删除已在事务中提交前完成，而插入尚未执行。
- 批量移动时，务必分页处理，单次事务控制在数百条以内（如每次 100 条）
- 不要在事务中调用外部 API、文件读写或 sleep，这些都会计入事务耗时
- 可通过
db.adminCommand({ setParameter: 1, transactionLifetimeLimitSeconds: 300 })临时调高限制（仅限副本集；分片集群需在每个分片上设置） - 监控事务状态可用
db.currentOp({ "secs_running": { "$gt": 30 } })查看长事务
集合不存在或权限不足会在事务开始前就报错
事务本身不延迟校验集合存在性或用户权限。如果 archived_orders 集合未创建，或当前用户没有对它的 insert 权限，withTransaction 调用会立即抛出异常，根本不会进入事务逻辑。
- 确保目标集合已存在，或提前用
db.createCollection()创建（该命令不能放在事务内） - 验证账号权限：至少需要
readWrite角色，且作用域覆盖两个集合（如db.orders和db.archived_orders） - 事务内无法建索引、改结构，DDL 操作一律禁止
跨集合移动的本质不是“复制+删除”，而是“带约束的两步写入”。真正容易被忽略的是会话生命周期管理——endSession() 必须调用，否则连接泄漏；而 withTransaction 内部重试机制可能多次执行回调，所以所有操作都得是幂等的（比如用 deleteOne 而非 deleteMany 匹配不确定条件）。
