MongoDB事务基于MVCC+2PC实现，非锁机制；需副本集/分片集群、readConcern:"majority"；事务为会话级+拓扑级协同，commit成功指多数节点oplog写入；禁止索引创建等非幂等操作；性能受复制延迟影响较大。
MongoDB 事务不是基于锁表或行锁实现的
MongoDB 的事务底层不依赖传统关系型数据库的锁机制（比如 MySQL 的行锁、Oracle 的 ITL），而是靠多版本并发控制（MVCC）+ 两阶段提交（2PC）来保证原子性。这意味着：事务内读操作默认是快照读（基于 oplog timestamp 或 clusterTime），不会阻塞其他写；写操作在 commit 前只对当前会话可见，不落盘到主数据集。
实操中要注意：
• session.startTransaction() 后所有操作必须在同一个 session 中执行，跨 session 的操作无法加入同一事务
• 事务生命周期受 transactionLifetimeLimitSeconds 限制（默认 60 秒），超时自动 abort
• 集合必须是副本集或分片集群（单节点不支持事务），且所有参与集合需启用 readConcern: "majority"
SQL 事务的 ACID 是引擎级保障，MongoDB 是会话级 + 拓扑级协同
MySQL 的 InnoDB 在存储引擎层就内置了完整的 redo log、undo log 和锁管理器，事务的原子性和持久性由引擎自己闭环完成。MongoDB 则把事务逻辑拆到了 mongod 进程（协调者）、oplog（日志载体）和复制协议（多数派写入确认）三层上——commit 成功 ≠ 数据已刷盘，而是「多数节点 oplog 已写入该事务的所有操作」。
常见错误现象：
• 写入后立刻用 readConcern: "local" 查询，可能看不到刚 commit 的数据
• 分片集群下跨分片事务要求所有分片都支持 4.2+ 且开启 featureCompatibilityVersion: "4.2"
• findAndModify 在事务中不能用 upsert: true（会触发隐式索引创建，违反事务限制）
事务内不能执行某些“非幂等”或“拓扑敏感”操作
MongoDB 明确禁止在事务中调用会影响集群状态或无法回滚的操作，这不是语法限制，而是架构约束。比如创建索引、修改用户权限、执行 collMod、调用 $out 或 $merge 聚合阶段——这些操作要么不支持回滚，要么需要广播到所有节点，与事务的局部快照语义冲突。
使用场景判断要点：
• 只有涉及多个文档/多个集合的强一致性写入才值得开事务（如扣库存 + 记订单 + 发通知）
• 单文档写入天然原子，用 updateOne + upsert 就够，不必套事务
• retryWrites: true 对单语句更轻量，别误当成事务替代方案
性能开销集中在复制延迟与锁等待窗口
MongoDB 事务 commit 阶段要等 oplog 被 majority 节点确认，所以实际延迟 = 网络 RTT + 从节点 apply 时间。相比 SQL 数据库本地 WAL 刷盘，这个过程更不可控。尤其在跨地域分片集群中，一次事务可能卡住几百毫秒。
参数差异提醒：
• maxCommitTimeMS 只控制 commit 阶段等待上限，不影响事务体执行时间
• writeConcern 设为 { w: "majority", j: true } 会进一步拖慢，但能避免 power loss 导致的数据丢失
• readConcern: "snapshot" 是事务内读的默认行为，但显式指定可避免因 driver 版本低导致降级成 "local"
容易被忽略的一点：事务 session 本身会占用内存和 oplog slot，长事务（>10s）可能推高主节点 oplog 增长速度，间接影响从节点同步压力。不是所有“需要一致性”的地方都适合上事务——有时候应用层补偿比硬扛事务更稳。
