mongodb事务不产生独立日志文件，oplog条目为≤16mb的bson文档，大事务自动拆分为多条关联oplog；transactiontoolargeforcache是wiredtiger缓存溢出错误，与oplog大小无关，需通过控制事务批次、避免重复修改和监控cache占用率来防范。
MongoDB 事务本身不产生独立的“事务日志文件”，你看到的 oplog（操作日志）条目大小受 BSON 16MB 硬限制约束，但单条 oplog 不会超限——MongoDB 已改用多条 ≤16MB 的 oplog 记录封装一个事务。
oplog 条目仍是 BSON 文档，单条上限 16MB
事务提交后，WiredTiger 会将变更序列化为 oplog 条目写入 local.oplog.rs。每个 oplog 条目本身仍是一个 BSON 文档，因此严格遵守单文档 16MB 上限（即 2^24 - 1 字节）。但关键点在于：MongoDB 4.4+ 已移除“单事务必须塞进一条 oplog”的旧逻辑。
- 一个大事务（比如修改 10,000 条文档）会被自动拆成多个 oplog 条目，每条 ≤16MB，彼此用
lsid和txnNumber关联 - 你不会看到单条 oplog 报
DocumentTooLarge；如果真遇到，说明某次写操作（如insertOne）本身超了 16MB，和事务无关 - 可通过
db.getSiblingDB("local").oplog.rs.findOne({ txnNumber: { $exists: true } })查看带事务标记的 oplog 样例
TransactionTooLargeForCache 错误不是 oplog 超限，而是 WiredTiger 缓存溢出
真正容易被误读为“日志超限”的错误是 TransactionTooLargeForCache，但它和 oplog 大小完全无关——它来自 WiredTiger 引擎在内存中暂存未提交变更时的缓存压力。
- 事务内所有未提交的写操作（包括旧版本文档快照）都驻留在 WiredTiger cache 中，直到
commitTransaction - 日志里出现
cache overflow或eviction pressure就是这个信号 - 盲目调大
wiredTigerCacheSizeGB可能掩盖问题，还挤占其他请求内存
避免事务引发缓存/日志相关失败的核心动作
别纠结“日志大小配置”，重点控制事务行为本身：
- 把批量写入拆成小批次：每批 ≤500 条
updateMany或insertMany，中间加await new Promise(r => setTimeout(r, 10))避免连续高压 - 禁用事务内非必要读取：尤其是
find().toArray()或无$hint的全集合扫描，它们也会占 cache - 检查是否重复修改同一文档：每次
$set都会生成新快照，旧版本滞留 cache 直到提交 - 确认失败事务是否已显式
abortTransaction：残留的 inactive 事务会持续锁住 cache 空间
最危险的情况是：你以为只改了 3 条文档，其中一条含 12MB base64 字段——实际 cache 占用接近 36MB（3×原始+快照）。这个膨胀是隐式的，监控 serverStatus.metrics.transaction.currentActive 和 wiredTiger.cache.maximum bytes configured 的比值比看日志更早发现问题。
