根本原因是默认配置和使用方式触发内存、时间、锁粒度等多重限制；事务越长修改越多，snapshot内存和journal缓冲越大，锁持有时间越长，易超时或OOM。
大批量数据写入 MongoDB 事务时，性能急剧下降甚至失败，根本原因不是事务本身不支持大操作，而是默认配置和使用方式触发了内存、时间、锁粒度等多重限制。直接用单个事务包 10 万条 insertOne 或 updateOne 几乎必然超时或 OOM。
为什么 MongoDB 事务对批量操作特别敏感
MongoDB 事务在 WiredTiger 存储引擎中依赖 snapshot isolation，所有修改必须在内存中维护一致性快照。事务越长、修改文档越多，占用的 snapshot 内存和 journal 缓冲就越大；同时事务持有读/写锁的时间也线性增长，阻塞其他操作。
-
maxTransactionLockRequestTimeoutMillis默认仅 60000（60 秒），超时直接报TransactionTooOld或InterruptedAtShutdown - 单事务最多可修改约 1000 个文档（非硬限制，但超过后 WAL 日志膨胀、oplog 写入延迟显著升高）
- 事务内不能跨分片执行写操作（sharded cluster 下，所有操作必须路由到同一 shard）
- 聚合管道中的
$merge、$out不支持在事务中使用
分批处理：控制每批次事务大小的实操边界
分批不是简单按数量切，而是要兼顾事务时长、内存压测结果和业务一致性语义。建议以「50–200 条写操作 / 事务」为起点调优，而非机械套用 1000 条。
- 优先按「业务逻辑单元」分批：例如一个订单含 3 张子表文档（orders、order_items、payments），这 3 条应在一个事务内，而不是强行拆成单文档事务
- 避免固定 size 分片：用
cursor.batchSize(n)拉取数据时，实际文档体积差异大，改用cursor.limit()+cursor.skip()易导致重复或遗漏；推荐用_id范围分片（如{ _id: { $gte: startId, $lt: endId } }） - 每批事务显式设置
maxTimeMS，例如session.startTransaction({ maxTimeMS: 30000 })，防止某批卡死拖垮整体 - 监控
db.currentOp({ "secs_running": { $gt: 10 } })快速识别长事务
事务颗粒度控制：哪些操作必须进事务，哪些可以放开
事务开销集中在「多文档原子性保障」上。若业务允许最终一致性，就该把非关键路径移出事务——这是比调参数更有效的性能杠杆。
- 日志类、统计类、通知类写入（如
audit_log、user_activity）一律不进事务；可用 change stream 或异步 job 补偿 - 索引构建、
$push到小数组、$inc计数器更新，本身是单文档原子操作，无需包裹事务 - 跨集合强一致性场景（如扣库存 + 生单），才需事务；若库存服务已用分布式锁隔离，MongoDB 层可降级为单文档写
- 避免在事务中调用外部 HTTP 接口或文件 IO，网络延迟会直接吃掉
maxTimeMS
真正难的不是写多少行代码实现分批，而是判断哪几条数据变更必须“同时成功或同时失败”。这个业务语义边界一旦模糊，再细的事务粒度也救不了性能——反而让问题更隐蔽。
