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就无法记录，主从数据必然断裂。
这意味着：
- 不存在“事务总大小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就会立刻抛出——这个边界没有商量余地。
