mongodb 6.2+ 中 transactiontoolargeforcache 错误不再自动重试，因服务端策略变更：事务超出内存缓存上限，重试无效；需通过拆分事务、避免大文档操作、调整 transactioncachesize 等方式解决。
TransactionTooLargeForCache 错误在 MongoDB 6.2+ 中不会被自动重试，这是和旧版本最显著的区别——你手动重试事务时，如果仍超出事务缓存限制，会反复失败。
为什么 TransactionTooLargeForCache 不再重试
MongoDB 6.2 起，服务端明确移除了对该错误的自动重试逻辑。这不是驱动或客户端的问题，而是服务器策略变更：事务太大意味着它已超过内存中事务缓存（transactionCacheSize）上限，继续重试只会重复触发同一错误。
- 该错误通常发生在事务内操作文档过多、单次修改体积过大（如批量更新含大字段），或事务持续时间过长导致缓存压力升高
-
retryWrites: true对此错误完全无效——它只影响单文档写操作，不覆盖事务边界 - 驱动层（如 Node.js 3.3.0+、Python 4.7+）也不会拦截并重试该错误；它原样抛出
如何判断是否真由事务体积引发
别急着改代码，先确认是不是缓存瓶颈。运行 db.runcommand({ serverstatus: 1 }) 并检查以下字段：
-
metrics.transaction.transactionTooLargeForCache计数是否持续增长 -
mem.resident和mem.virtual是否接近节点内存上限 -
transactions.open和transactions.totalStarted的比值是否异常高（说明事务堆积）
如果这些指标异常，基本可锁定是事务设计问题，而非网络抖动或临时锁竞争。
实际可行的降级与拆分方案
根本解法不是加重试次数，而是缩小事务作用域。以下做法经生产验证有效：
- 把单个大事务拆成多个小事务，用业务主键或时间窗口分片（例如按
user_id % 10分组处理） - 避免在事务中读取/修改超 1MB 的文档；对大字段（如 base64 图片、长文本）改用单独非事务写入
- 用
db.collection.find().limit(n).batchSize(n)控制游标批量大小，防止事务内隐式加载过多数据 - 确认
transactionCacheSize配置合理（默认 100MB），但不要盲目调高——它占用 WiredTiger 缓存，可能挤压查询性能
最容易被忽略的是：事务里嵌套的 upsert 在 MongoDB 7.0.22+ 也不再重试重复键错误，这意味着如果你靠 upsert 实现幂等，得额外加唯一索引 + 显式 try/catch 捕获 11000 错误——这和 TransactionTooLargeForCache 是不同维度的问题，但常被混为一谈。
