MongoDB大事务需规避transactionLifetimeLimitSeconds超时与WiredTiger内存溢出，须按业务实体或时间窗口拆分并保障幂等性，不可仅靠循环或重试解决。
拆分 MongoDB 大事务不是“加个循环就能解决”的事，而是要直面两个硬约束：服务端 transactionLifetimeLimitSeconds（默认 60 秒）和 WiredTiger 内存缓存上限。超时或事务过大直接触发 TransactionTooLargeForCache 或 MaxTimeMSExpired，此时重试无效，必须从结构上降载。
为什么大事务容易在 commit 阶段失败
事务提交失败往往不是代码写错了，而是事务生命周期或资源占用越界了。MongoDB 在 commit 前会做两件事：一是校验所有修改是否仍可应用（比如文档没被其他事务覆盖），二是把全部变更刷入 journal 并同步到多数节点。这两步都卡在单次网络往返里，一旦事务内操作过多、文档过大、索引更新频繁，就会拖慢 commit 本身——哪怕你设了 max_commit_time_ms=10000，也扛不住底层锁竞争或日志写放大。
-
TransientTransactionError类错误（如WriteConflict）可由驱动自动重试，但仅限“临时冲突”，不包括超时或内存溢出 -
TransactionTooLargeForCache自 MongoDB 6.2 起不再自动重试，说明事务已超出 WiredTiger cache 容量，必须拆 - 事务中含
upsert且命中唯一键冲突时（尤其多文档事务），MongoDB 7.0.22+ 不再重试，直接失败
按数据粒度拆：别让一个事务跨多个业务实体
典型误区是“把一批订单状态更新包进一个事务”，看似原子，实则把无关订单耦合在一起。只要其中任一订单关联的文档被并发修改，整个事务就可能因写冲突回滚。正确做法是让事务边界对齐业务实体边界。
- 每个事务只操作同一个
_id或同一组强关联字段（例如：一个用户 profile + 其最近一条 activity 记录） - 避免在单事务中混合读写不同集合，尤其是跨分片集合；
startTransaction()后首次操作决定该事务的路由分片，后续操作若跨 shard 会强制广播，显著拖慢 - 批量更新场景下，用
bulkWrite()替代循环调用updateOne()，但注意：bulkWrite 本身不构成事务，必须显式包裹在 session 内，且每条操作仍需满足单文档事务粒度
按时间窗口拆：用 checkpoint + 幂等写代替长事务
真正无法拆成小事务的场景（比如迁移百万级用户积分），不能硬扛，得换思路：放弃“全量原子”，改用“分段确认 + 最终一致”。核心是把“事务内状态”外移到数据库字段中，靠应用层控制进度。
- 在源集合加
processed_at: null字段，每次取 1000 条未处理记录，更新其processed_at为当前时间戳（带upsert: false和collation避免重复），再执行业务逻辑，最后批量更新目标表——每批独立事务 - 关键：所有更新操作必须幂等，例如用
$setOnInsert或条件更新{"processed_at": null}，防止重试导致重复扣款 - 不要依赖客户端计时器控制批次间隔，而应以数据库写入结果为准；上一批
commit_transaction()成功后，再拉下一批
检查并压测你的实际事务开销
拆之前先确认瓶颈在哪。光看代码行数没用，得看真实内存和时间消耗：
- 开启 MongoDB 日志级别为
2（db.setLogLevel(2, "storage.journal")），观察事务 commit 阶段的wt_txn_commit耗时 - 用
db.currentOp({ "secs_running": { "$gt": 5 } })抓住慢事务，检查其lsid对应的 session 操作列表 - 在测试环境模拟生产负载，用
mongostat --host <shard>观察netIn/netOut和flushes是否突增——这是事务日志写放大的信号
最易被忽略的一点：事务拆分后，应用层必须接管原本由数据库保证的“全局顺序”。比如原事务中 A→B→C 的严格先后，在分批执行时可能变成 A₁→B₁→A₂→C₁，若业务依赖 C 必须在 B 之后才生效，就得加分布式锁或版本号控制。这不是 MongoDB 的问题，而是拆事务必然带来的权衡。
