事务内多次修改同一文档会生成多条Oplog记录，因oplog不合并、逐条落盘以保证secondary重放一致性；updateMany和bulkWrite在事务中同样按匹配/操作数生成对应条目。
事务内多次修改同一文档会生成多条 Oplog 记录
MongoDB 的 oplog 不做合并，事务里对同一个文档反复 $set、$inc 或 save()，每改一次就记一条日志。哪怕最终只存最后一次值，oplog 仍按执行顺序逐条落盘——这是为了保证下游 secondary 重放时的精确行为一致性。
常见错误现象：
- 事务中循环调用
findOneAndUpdate更新同一字段（比如 status → pending → processing → done） - 业务逻辑写成「查→改A→改B→改C→提交」，而非单次
$set: {a: x, b: y, c: z} - 使用 ORM 封装的
save()方法，在事务内被多次触发
实操建议：
- 检查应用代码里是否存在嵌套更新逻辑，优先合并为原子更新操作
- 用
db.adminCommand({currentOp: {allUsers: true, $or: [{secs_running: {$gt: 5}}, {active: true}]}})找出长事务，重点看secs_running和numYields - 避免在事务中调用可能隐式触发多次写入的封装方法（如 Mongoose 的
doc.save()）
updateMany 和 bulkWrite 在事务中放大 oplog 体积
事务本身不改变 oplog 条目生成规则：一次 updateMany 匹配 N 条文档，就会产生 N 条 oplog；bulkWrite 中每个 updateOne 操作也各自独立记日志。事务只是把它们包进一个原子上下文，但不会压缩或去重。
使用场景：
- 批量状态迁移（如订单从
created→shipped→delivered）放在一个事务里执行 - 数据清洗脚本在事务中分步更新多个字段
参数差异与影响：
-
updateMany默认multi: true，匹配多少文档就写多少 oplog 条目 -
bulkWrite([{updateOne: {...}}, {updateOne: {...}}])中每个操作都单独生成 oplog，和是否在事务中无关 - 事务开启后，所有写操作延迟到 commit 才刷盘，但 oplog 条目已在内存中逐条构造完毕
如何快速定位事务引发的 oplog 暴涨源头
不能只看 db.serverStatus().metrics.operation.write.ops，它统计的是请求次数，不是 oplog 实际条目数。真正要盯的是 oplog 集合本身的增长速率和单条记录密度。
实操步骤：
- 运行
db.getSiblingDB("local").oplog.rs.stats()查当前大小、平均对象大小（若avgObjSize明显偏小，说明大量细粒度更新） - 对比
db.serverStatus().metrics.repl.buffer.count和.sizeBytes，若 buffer 积压严重，说明 secondary 同步慢，加剧 oplog 占用假象 - 启用 profiling：
db.setProfilingLevel(2, {slowms: 100})，再查db.system.profile.find({op: "command", command: {$regex: /commitTransaction|abortTransaction/}})，结合ts字段回溯前后写操作
容易踩的坑：误以为“事务少=oplog 少”，其实关键在事务内写了几次、改了几条、是否重复更新同一文档。
oplog 暴涨时 secondary 同步延迟会掩盖真实问题
当从节点同步跟不上，主节点必须保留旧 oplog 等它拉取，导致 local.oplog.rs 看似“暴涨”，实际是卡住而非真写得多。这种情况下增大 oplogSizeMB 只是延缓问题，不解决根本。
判断依据：
- 执行
rs.printSecondaryReplicationInfo()，看optimes.lastCommittedWallTime和optimes.lastAppliedWallTime差值是否持续扩大 - 检查
db.printSlaveReplicationInfo()输出的syncedTo时间戳是否明显落后于当前时间 - 对比主节点
db.serverStatus().metrics.repl.apply.batches.num和从节点的该值，若后者长期为 0，说明已断连或卡死
复杂点在于：oplog 增长快 + secondary 延迟高，两者互为因果。先确认是写入侧真猛，还是复制侧真慢——否则优化方向全错。
