在 mongodb 7.0 中，对大批量数据（如 >10 万条）使用单事务 insertmany 是高风险操作，writeconflict 和 transactiontoolargeforcache 错误几乎必然发生；安全做法是弃用事务封装，改用带 writeconcern: { w: "majority", j: true } 的无事务批量写入，并分批控制体积。
直接结论：在 MongoDB 7.0 中，对大批量数据（如 >10 万条）使用单事务 insertMany 是高风险操作，WriteConflict 和 TransactionTooLargeForCache 错误几乎必然发生；安全做法是弃用事务封装，改用带 writeConcern: { w: "majority", j: true } 的无事务批量写入，并分批控制体积。
为什么不能把 80 万条塞进一个事务里？
MongoDB 7.0 虽支持长事务，但 WiredTiger 缓存需为整个事务维护快照、预写日志和检查点页。默认 wiredTigerCacheSizeGB（物理内存的 50%）在百万级文档写入时迅速耗尽，触发 WriteConflict ——这不是业务冲突，而是存储引擎因内存争用强制中止。同时，事务生命周期超过 transactionLifetimeLimitSeconds（默认 60 秒）也会被后台清理进程杀死。
- 事务内写入总数据量建议控制在 百 MB 级以内，而非百万文档级
- 单事务执行时间务必 ，否则会被静默中止
- 即使调大缓存，也无法绕过 oplog 条目单条 ≤16MB 的硬限制（虽已取消事务总大小限制）
必须用事务时，如何最小化风险？
仅当跨文档强一致性不可妥协（如 A 集合插入 + B 集合更新必须原子）才启用事务。此时必须拆分边界，绝不可“一锅炖”：
- 每批
insertMany放在独立短事务中，例如batchSize = 1_000，每个事务只含一次写入 - 显式捕获
TransientTransactionError并重试整个事务（驱动不自动重试） - 提交时加
maxTimeMS: 30000防止卡死，尤其在分片集群上 - 确认所有节点
featureCompatibilityVersion≥ 4.2（分片集群要求）
示例关键逻辑（Java 驱动）：
for (List<document> batch : batches) {
session.startTransaction(TransactionalOptions.builder()
.maxCommitTime(30, TimeUnit.SECONDS)
.build());
try {
collection.insertMany(session, batch);
session.commitTransaction();
} catch (MongoException e) {
if (e.hasErrorLabel("TransientTransactionError")) {
session.abortTransaction(); // 必须显式中止再重试
continue;
}
throw e;
}
}</document>
更推荐：完全弃用事务，靠 writeConcern 保安全
95% 的批量导入场景（如 ETL、日志归档）无需事务。用合理 writeConcern + 分批 + 重试机制，吞吐更高、错误更少：
- 设置
writeConcern: { w: "majority", j: true }：确保数据落盘且同步到多数节点，防主节点宕机丢数据 - 单批控制在
5_000 ~ 10_000文档，避免单次网络包超限或 OOM - 对
writeConcernError（如网络分区导致 majority 未达成）做指数退避重试 - 禁用
retryWrites（默认 true），因批量写入本身不幂等，重试需业务层判断
Quarkus 中典型配置片段：
mongoClient.getDatabase("db").getCollection("coll")
.withWriteConcern(WriteConcern.MAJORITY.withJournal(true))
.insertMany(batch);
容易被忽略的底层配置项
即使代码层做对了，WiredTiger 缓存不足仍会让 WriteConflict 反复出现，尤其在容器或低配 VM 中：
- 检查当前值：
db.adminCommand({ getParameter: 1, wiredTigerCacheSizeGB: 1 }) - 生产环境建议手动设为物理内存的 60%~70%，但不低于 4GB（
wiredTigerCacheSizeGB: 4） - 若用 MongoDB Atlas，需在集群配置页调整
WiredTiger Cache Size，而非连接字符串参数 - 注意：该参数需重启
mongod生效，且会影响其他并发读写性能
真正棘手的是缓存压力与事务中止的循环——未提交事务会持续占满缓存，导致新事务连启动都失败。所以，永远优先从应用逻辑剥离事务，而不是调大缓存硬扛。
