TransactionTooLargeForCache错误源于WiredTiger缓存过载，非16MB文档限制；事务未提交前所有写操作暂存缓存，超阈值即中止，需拆分小事务、避免重复改同一文档、减少非必要读取并监控aborted和largerThanCache指标。
TransactionTooLargeForCache错误不是数据量超限，而是WiredTiger缓存被撑爆
这个错误和文档总大小是否超过16MB完全无关——MongoDB早就不受该限制了。真正触发中止的是WiredTiger引擎的内存缓存压力：事务中所有未提交的写操作（updateMany、insertMany、反复$set大字段）都会暂存在缓存里，直到commitTransaction。一旦缓存占用逼近阈值，引擎会主动拒绝继续执行，返回TransactionTooLargeForCache。
日志里如果出现cache overflow或eviction pressure，基本可以确认是这个原因。它也不是靠调大cacheSizeGB就能解决的——盲目扩容可能掩盖真实瓶颈，还挤占其他请求的内存资源。
归档类操作天然具备高缓存杀伤力
大批量归档通常意味着：find扫描大量旧文档 + insertOne写入归档集合 + deleteOne清理原集合。这三个动作在事务内串联，会同时触发三重缓存压力：
- 读操作（尤其没走覆盖索引的
find）会把大量文档加载进缓存，且readConcern: "snapshot"还会延长MVCC版本链 - 每个
insert都生成新文档副本，每个delete都保留旧版本直到提交 - 反复修改同一文档（比如归档时顺手更新
archivedAt字段）会让旧版本持续驻留，缓存占用呈指数增长
替代方案比硬扛事务更可靠
归档本质是“可接受短暂不一致”的后台任务，没必要强求ACID：
- 用
bulkWrite分批处理，每批≤500条，中间加sleep(100)错峰，避免连续高压 - 归档前先
createIndex确保find走索引，禁用readConcern: "snapshot"（默认local足够） - 删除操作改用
deleteMany而非循环deleteOne，减少事务内操作数 - 确认归档集合已启用TTL索引（如
{archivedAt: 1}+expireAfterSeconds），让过期清理交给后台线程
监控比报错后救火更重要
这个错误没有固定阈值，它取决于当前并发数、文档结构、缓存负载等动态因素。比起盯着单次报错，更应关注：
-
db.serverStatus().metrics.transaction.aborted是否突增 -
db.serverStatus().metrics.transaction.largerThanCache是否持续非零 -
db.currentOp({secs_running: {$gt: 30}})是否有长事务卡在prepare阶段
真正难处理的点在于：它往往在业务高峰期才暴露，而此时你已经没法临时拆事务——预案必须提前埋好。
