MongoDB 不支持 SAVEPOINT 机制，因其事务模型为“全有或全无”，且副本集+oplog 的追加式日志设计不支持中间回滚；需通过应用层拆分事务并状态兜底实现类似效果。
MySQL 的 SAVEPOINT 在 MongoDB 里根本不存在
MongoDB 不支持 SAVEPOINT、ROLLBACK TO SAVEPOINT 或 RELEASE SAVEPOINT 这类语句——它压根没有保存点（savepoint）机制。这不是版本问题，也不是配置没开，而是设计上就不提供。MongoDB 的事务模型是“全有或全无”：要么整个 with_transaction 块成功提交，要么在任意一步失败时自动回滚全部操作，无法部分回退。
为什么 MongoDB 不做 Savepoint？
根本原因在于副本集 + oplog 的复制机制。MySQL 的 savepoint 依赖 undo log 和精细的事务状态快照，而 MongoDB 的事务日志（oplog）是追加式、不可逆的线性记录，不支持“在中间某点截断并重放”。再加上事务必须满足 w: "majority" 才能提交，一旦写入 majority 节点，就已进入不可逆同步路径，没法只撤回其中一段。
- 事务内所有操作共享同一个 oplog 条目时间戳，无法按子步骤打标记
- 从节点靠重放 oplog 同步，没有“跳过某几条”的语义支持
- Mongoid 或官方 driver 的
session.with_transaction底层只调用startTransaction/commitTransaction/abortTransaction，没有暴露 savepoint 接口
想实现“类似 Savepoint”的效果，只能手动拆事务
如果你需要“先扣库存，再创建订单，失败时只回滚订单、保留扣减”，MongoDB 无法靠数据库原生能力做到。必须把逻辑拆成多个独立事务，并用应用层状态兜底：
- 第一步：用独立事务执行库存扣减，成功后写入一个带唯一 ID 的临时状态（如
inventory_locks集合），记录操作时间与业务上下文 - 第二步：尝试创建订单；若失败，用另一个事务去查
inventory_locks，决定是否补回库存（需幂等处理） - 避免在单个事务里混写多个集合的关键操作——这会放大失败影响面，也掩盖了真实的业务边界
示例伪代码：
session.with_transaction do
inventory.update_one({ _id: id }, { "$inc" => { quantity: -1 } })
# ❌ 别在这里直接 create_order！一旦失败，库存扣减也白费
end
别被 Mongoid 文档里的 “savepoint” 表述误导
极少数旧版 Mongoid 插件或社区文章里提到 “savepoint”，实际指的是 Ruby 层的 ActiveRecord::Base.transaction 回滚点（比如测试中用 DatabaseCleaner），和 MongoDB 无关。MongoDB 官方文档、驱动源码、Wire Protocol 规范里，从未定义或实现过 savepoint 相关命令。只要看到 ROLLBACK TO SAVEPOINT 报错 CommandNotFound 或驱动抛出 UnsupportedOp，就是确认信号。
真正容易被忽略的是：事务不是万能胶，尤其在跨集合、跨服务场景下，越想靠一个事务包揽所有，越容易掉进“回滚不可控 + 锁等待超时 + 复制延迟放大错误”的坑里。
