mongodb事务不支持sql风格隔离级别枚举，其隔离行为由readconcern参数控制，仅在starttransaction时指定；readconcern:"majority"防脏读但不保证跨分片一致性，readconcern:"snapshot"提供快照隔离并防止不可重复读与幻读。
MongoDB 事务不支持 SQL 风格的隔离级别枚举
MongoDB 没有 SET TRANSACTION ISOLATION LEVEL READ COMMITTED 这类语句，也不提供可选的“可重复读”“串行化”等命名级别。它的事务隔离行为由 readConcern 参数控制，且只在事务启动时（session.startTransaction()）通过选项传入——不是运行时动态切换的配置。
常见误解是把 readConcern: "majority" 当作“读已提交”，把 readConcern: "snapshot" 当作“可重复读”。这种类比容易误导：前者解决的是“能否看到未被多数节点确认的数据”，后者解决的是“能否跨分片看到同一时间点的一致快照”，二者关注的问题维度不同。
readConcern: "majority" 的实际行为和限制
这是 MongoDB 事务的默认 readConcern（即使不显式指定）。它保证你读到的数据已被大多数副本集成员（或分片主节点）持久化并确认提交，因此不会出现脏读。
- 在单副本集场景下，基本等价于“读已提交”语义，但底层不依赖锁，而是靠 WiredTiger 的 MVCC 版本链 + oplog 投票确认
- 在分片集群中，
"majority"不保证跨分片的时间线一致性：一个事务可能从 shard A 读到 t1 时刻的状态，从 shard B 读到 t2 时刻的状态（t1 ≠ t2），导致逻辑上不一致的中间态 - 无法防止“写倾斜（write skew）”：两个并发事务各自读取不重叠的文档集、做出互不冲突的修改、然后都成功提交，结果违反业务约束（例如：总库存超限）
- 不提供事务内多次读取的严格一致性保障——同一事务中两次
find()可能返回不同结果（如果其他事务在这之间提交了新文档，且满足查询条件）
readConcern: "snapshot" 才真正提供跨分片快照隔离
只有显式设置 readConcern: "snapshot"，事务才能获得真正的快照隔离（Snapshot Isolation），这也是 MongoDB 唯一能提供跨分片时间点一致性的选项。
- 必须配合
writeConcern: { w: "majority" }使用，否则会报错IllegalOperation: snapshot reads require majority write concern - 事务开始时，系统会为整个集群（含所有相关分片）确定一个全局一致的快照时间戳（logical timestamp），后续所有读都基于该快照，包括跨分片的聚合、多文档更新等
- 能防止“不可重复读”和“幻读”（在单集合范围内），也能防止多数写倾斜场景（因为所有读都锁定在同一个快照点）
- 注意：它仍不等同于 SQL 的
SERIALIZABLE，因为不检测“读-写冲突”，仅靠“写-写冲突检测（fail-on-conflict）”回滚事务，所以极少数写倾斜仍可能发生（需应用层加额外检查）
为什么不能用 readConcern: "local" 做事务读
"local" 允许读取尚未被多数节点确认的数据，常用于非事务性、低延迟要求的报表查询。但它明确**禁止在事务中使用**。
- 事务启动时若指定
readConcern: "local"，驱动会直接抛出错误：InvalidOptions: readConcern 'local' is not allowed in transactions - 根本原因：事务的 ACID 要求强一致性，“local”破坏了“已提交”这一前提，无法保证原子性和持久性语义
- 即便绕过驱动校验强行发请求，mongod 也会拒绝执行，并返回
CommandNotSupported: readConcern local is not supported in transactions
快照隔离不是“更高级的读已提交”，它是另一条技术路径：用时间戳锚定数据版本，而非用多数派确认锚定提交状态。实际选型时，若业务涉及跨分片强一致性（如金融对账、库存扣减+订单生成联动），"snapshot" 是唯一可靠选择；若只是单分片或容忍轻微不一致，"majority" 足够且性能更好。别被“隔离级别”这个词带偏——MongoDB 的设计哲学是“用正确工具解正确问题”，而不是套 SQL 标准的壳。
