MongoDB事务中单文档超16MB（即2²⁴−1字节）必报DocumentTooLarge错误，因BSON协议硬性限制；事务不放宽该限制，oplog、快照内存、分片等均受此约束，唯一合规方案是拆分文档或用GridFS存大文件。

事务内单文档超16MB直接报DocumentTooLarge

不是事务设了16MB限制，而是MongoDB底层BSON协议硬性规定单文档最大为2^24 - 1字节（即16MB − 1B）。事务里每个insertOne、updateOne、findAndModify操作仍走同一套BSON解析逻辑，只要序列化后文档体积超过该值，立刻抛出WriteCommandError: { code: 10334, errmsg: "Document is larger than 16MB" }。

常见踩坑点：

• 误以为transactionLifetimeLimitSeconds能放宽大小限制——它只控制事务存活时长，和文档尺寸完全无关
• 在事务中调db.collection.find().toArray()，把大结果集全加载进内存再进快照，实际占用远超16MB
• 用$projection返回大量字段，导致findAndModify响应体超限被拦，错误现象一样但根源在读操作

大事务引发WiredTiger缓存耗尽甚至OOM

MongoDB事务在内存中维护所有被修改文档的原始版本快照。修改1万条文档，或单条含20MB二进制字段，快照内存就可能达数十GB。WiredTiger引擎缓存（wiredTigerCacheSizeGB）一旦撑满，OS会触发OOM Killer杀掉mongod进程。

关键事实：

• maxTransactionLifetimeMinutes必须显式压低（如设为2），默认60分钟对高并发场景极危险
• 事务内循环调updateOne比单条updateMany更耗内存——每轮都追加一份旧文档副本
• serverStatus.metrics.transaction.currentActive × 平均文档大小 > 0.7 × wiredTigerCacheSizeGB 就该告警

Oplog与复制一致性强制约束事务粒度

事务提交后，所有写操作要拆成多个oplog条目同步到从节点。每个oplog条目仍是BSON文档，仍受16MB单文档限制。若允许超限事务，oplog就无法记录，主从数据必然断裂。

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

这意味着：

• 不存在“事务总大小16MB”这种说法——oplog已取消该总限，但每个子操作仍独立受16MB约束
• 分片集群中事务跨分片时，各分片各自生成oplog，压力分散但约束不变
• 别指望调大oplogSizeMB来解决问题——它只影响历史长度，不改单条上限

真正可行的应对方式只有两种

事务不是大数据搬运工具，它的设计目标是保障多步业务逻辑原子性，而非突破存储边界。所有“绕过”想法都会失败。

可落地的选择：

• 用GridFS存大内容，但必须同步写元数据文档到用户集合，file_id字段严格等于fs.files._id，所有查询字段（如deviceId、timestamp）显式建索引
• 拆文档：把大数组（如日志列表）抽到独立集合，主文档只留logRefId引用；分页、排序、统计需由应用层承担
• 绝对不要对fs.chunks或fs.files做聚合——它们不支持$match、$sort、$lookup，字段不可索引

最容易被忽略的是：哪怕你用分片集群、调高transactionLifetimeLimitSeconds、加大WiredTiger缓存，只要一次insertOne传入的文档序列化后超过16MB，WriteCommandError就会立刻抛出——这个边界没有商量余地。