i、u、d 分别对应 insert、update、delete 操作i 的 o 是完整文档u 的 o 是更新器且需结合原文档计算d 的 o 是删除条件oplog 不提供快照无事务边界格式随版本变化云服务常限制访问。Oplog 里的 i、u、d 分别对应什么操作它们是 MongoDB 副本集 oplogoperations log中记录变更的最简操作类型标识不是命令也不是状态而是服务端写入 oplog 时自动打上的动作标签iinsert表示一条新文档被插入到集合中oplog 条目里 o 字段是完整文档内容uupdate表示已有文档被修改o 是更新器如 {$set: {...}}o2 是匹配条件通常是 {_id: ...}ddelete表示文档被删除o 是删除条件如 {_id: ObjectId(...)}没有 o2注意u 和 d 都不记录原始文档快照只记“怎么改”或“删谁”这是做增量同步时容易漏掉数据的关键点。为什么不能直接靠 o 字段还原出变更后的文档因为 o 在不同操作类型下语义完全不同硬解析会出错i 的 o 是完整文档 → 可直接用u 的 o 是更新操作符如 {$set: {a: 1}, $inc: {b: 2}}→ 必须结合原文档计算结果d 的 o 是查询条件 → 不含任何字段值无法还原被删内容常见错误写监听脚本时统一取 o 当作新文档结果 u 和 d 场景下拿到的是垃圾数据。真实场景中要做字段级变更同步必须搭配上游数据库的读取能力比如用 find 查原文档再 apply update。从 oplog 里安全读取变更的几个硬约束oplog 不是通用日志接口它设计目标是副本集内部复制对外暴露有严格限制 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。