根本原因是默认配置和使用方式触发内存、时间、锁粒度等多重限制；事务越长修改越多，snapshot内存和journal缓冲越大，锁持有时间越长，易超时或OOM。
处理大批量数据时，如果一股脑儿全塞进一个MongoDB事务里，性能断崖式下跌甚至直接失败，是很多开发者都踩过的坑。问题出在哪儿？其实，事务本身并非不能处理大操作，真正的瓶颈往往藏在默认配置和常规的使用习惯里。内存、时间、锁粒度这几重限制一叠加，直接用一个事务包裹十万条insertOne或updateOne，超时或者内存溢出（OOM）几乎成了必然结局。
为什么 MongoDB 事务对批量操作特别敏感
这得从MongoDB事务的底层机制说起。在WiredTiger存储引擎下，事务依赖快照隔离（snapshot isolation）来保证一致性。这意味着，事务过程中所有要修改的数据，都得在内存里维护一份一致性快照。于是，事务持续的时间越长，涉及的文档越多，这份快照占用的内存以及预写日志（journal）的缓冲区就会像滚雪球一样越滚越大。与此同时，事务持有的读写锁时间也水涨船高，直接阻塞其他并发操作，整个系统的吞吐量就下来了。
几个关键的限制点需要特别注意：
- 事务锁请求的超时时间（
maxTransactionLockRequestTimeoutMillis）默认只有60000毫秒，也就是60秒。一旦超时，TransactionTooOld或InterruptedAtShutdown这类错误就来了。 - 虽然没有严格的硬性规定，但单事务修改的文档数量一旦超过1000这个经验阈值，WAL日志的膨胀和oplog写入的延迟就会变得非常明显。
- 在分片集群环境下，事务内的所有写操作必须路由到同一个分片，无法跨分片执行。
- 聚合管道中的
$merge和$out这类阶段，目前还不支持在事务中使用。
分批处理：控制每批次事务大小的实操边界
说到应对之策，分批处理是绕不开的方案。但这里的分批，可不是简单地按数量切几刀就行，必须综合考虑事务时长、内存压力测试结果，尤其是业务本身的一致性要求。通常，以“每批次50到200条写操作”作为调优起点，会比机械地套用1000条上限要靠谱得多。
具体操作时，有几个原则值得遵循：
- 按“业务逻辑单元”分批，而非按“文档数量”分批。 举个例子，一个订单可能涉及主订单表、订单项表、支付记录表三张子表。这三条关联记录，理应放在同一个事务里保证原子性，而不是为了凑数，硬把它们拆到不同批次去。
- 避免使用不稳定的分页方式。 用
cursor.batchSize(n)拉取数据时，由于每条文档的实际体积差异可能很大，固定的批次大小并不稳定。而使用cursor.limit()加cursor.skip()则容易在数据变动时导致重复或遗漏。更推荐的做法是基于_id这类有序字段进行范围分片，比如使用{ _id: { $gte: startId, $lt: endId } }这样的查询条件。 - 为每批事务显式设置超时。 在启动事务时，通过
session.startTransaction({ maxTimeMS: 30000 })这样的方式设置一个合理的超时时间（例如30秒），可以有效防止某一批次操作卡死，进而拖垮整个批量处理流程。 - 主动监控长事务。 定期运行
db.currentOp({ “secs_running”: { $gt: 10 } })这样的命令，能够快速识别出运行时间过长的操作，便于及时干预。
事务颗粒度控制：哪些操作必须进事务，哪些可以放开
事务的性能开销，核心在于为“多文档原子性”提供保障。因此，提升性能最有效的杠杆之一，其实是在设计阶段就厘清业务边界：如果某些操作允许最终一致性，那就果断把它们移出事务。这比事后调优任何参数都管用。
可以遵循以下策略来精细化控制事务粒度：
- 日志、统计、通知类写入一律“非事务化”。 像操作审计日志（
audit_log）、用户行为记录（user_activity）、发送通知这类场景，对实时一致性要求不高，完全没必要放进事务。可以通过Change Stream监听变化，或者用异步任务来补偿实现。 - 利用MongoDB的单文档原子操作。 诸如创建索引、向小数组进行
$push、用$inc更新计数器这类操作，MongoDB在单文档级别已经保证了原子性，无需额外包裹事务。 - 只在真正的跨集合强一致性场景使用事务。 比如“扣减库存”和“生成订单”必须同时成功或失败，这才需要事务。如果库存服务已经通过分布式锁做了隔离，那么在MongoDB这一层，甚至可以降级为更高效的单文档写操作。
- 事务内避免调用外部服务。 切忌在事务中执行HTTP接口调用或文件IO操作。网络延迟的不确定性会直接消耗宝贵的
maxTimeMS，极大增加事务失败的风险。
说到底，真正的难点往往不在于写出分批处理的代码，而在于准确判断：哪几条数据变更在业务逻辑上必须“同生共死”。这个业务语义的边界一旦模糊，无论把事务粒度切得多细，都难以挽救性能，反而可能让问题变得更加隐蔽和复杂。
