作为 NoSQL 数据库的代表，MongoDB 的事务能力一直被部分开发者 “低估”—— 不少人还抱着 “老版本有坑”“NoSQL 事务不靠谱” 的固有印象。但实际上，自 4.0 版本支持多文档事务后，MongoDB 已实现 ACID 兼容，其基于快照隔离（Snapshot Isolation）的设计，不仅能媲美传统关系型数据库的一致性，还通过独特的冲突处理机制兼顾了性能。本文结合完整实测代码和案例，带大家彻底搞懂 MongoDB 的事务隔离级别，厘清那些流传已久的误解。

一、核心结论：MongoDB 事务隔离级别的本质

MongoDB 的多文档事务采用快照隔离（Snapshot Isolation） 机制，依托多版本并发控制（MVCC）实现强一致性，完全满足 ACID 特性。

很多开发者会下意识将其与 SQL 标准的隔离级别对标，但这种做法并不恰当 ——SQL 标准的隔离级别定义并未考虑 MVCC，而 MongoDB、PostgreSQL 等主流数据库均依赖 MVCC 实现并发控制。简单来说：

MongoDB 的事务隔离能力不逊色于传统关系型数据库；

早期版本（如 4.0 刚支持多文档事务时）的部分问题已完全修复，像早期 Jepsen 报告中提到的异常场景已不复存在；

其隔离级别通过 readConcern（读关注级别）控制，不同级别对应不同的一致性保障和使用场景。

二、各读关注级别的特点（与 SQL 隔离级别的区别）

MongoDB 的事务隔离核心由 readConcern 参数控制，不同级别对应不同的一致性表现，且无法直接等同于 SQL 标准的隔离级别，具体特点如下：

1. local 级别

可能读取到未提交的中间状态（这些状态后续可能因事务回滚而失效），因此有时被类比为 SQL 的 “读未提交”；

但需注意：部分 SQL 数据库在极端情况下也会出现类似行为，却仍将其归为 “读已提交” 级别，可见直接对标并不严谨。

2. majority 级别

仅读取已被大多数节点确认提交的数据，避免了 “读未提交” 问题，常被类比为 SQL 的 “读已提交”；

关键区别：SQL 的 “读已提交” 是为了减少两阶段锁的锁定时长，采用 “冲突等待” 机制；而 MongoDB 多文档事务采用 “冲突即失败”（fail-on-conflict）机制，避免长时间等待；

局限：在多分片场景下，可能读取到多个不同时间点的状态，无法保证跨分片的时间线一致性。

3. snapshot 级别

真正等同于 “快照隔离”，能提供跨分片的时间线一致性，防止的异常场景比 “读已提交” 更多；

有趣的是：部分数据库会将其称为 “可串行化”，因为 SQL 标准并未考虑 “写倾斜”（write skew）异常，而快照隔离本身可规避部分此类场景。

4. linearizable 级别

仅适用于单文档操作，无法用于多文档事务，可类比为 SQL 的 “可串行化”；

特点：能保证单文档操作的线性一致性，但会重新引入读锁带来的扩展性问题，这也是多数数据库不默认提供可串行化级别的原因 ——MVCC 的核心优势就是避免读锁。