是的，MongoDB 支持 ACID 事务。

虽然 MongoDB 是 NoSQL 数据库，但它已经发展出了与传统关系型数据库（RDBMS）类似的事务能力。以下是详细的发展历程和支持范围：

1. 支持的演进历史

• 早期版本（一直支持）：单文档原子性 (Single-Document Atomicity)
  MongoDB 的设计核心是文档模型。由于一个文档可以包含嵌套的数组和子文档，很多在关系型数据库中需要跨表事务的操作（例如更新订单头和订单行），在 MongoDB 中只需要更新一个文档即可。这种针对单个文档的操作一直是原子的（Atomic）。
• MongoDB 4.0 (2018年)：副本集多文档事务
  引入了对副本集（Replica Sets）的多文档 ACID 事务支持。这意味着你可以在一个事务中更新多个集合（Collections）甚至多个数据库中的数据，要么全部成功，要么全部回滚。
• MongoDB 4.2 (2019年)：分片集群分布式事务
  引入了对分片集群（Sharded Clusters）的分布式事务支持。这标志着 MongoDB 实现了全面的 ACID 事务能力，无论数据分布在多少个节点上。

2. ACID 在 MongoDB 中的具体表现

MongoDB 的事务机制基于 WiredTiger 存储引擎，具体表现如下：

• A (Atomicity - 原子性): 事务中的所有操作要么全部完成，要么全部不完成。如果事务中止（abort），所有修改都会回滚，对外部不可见。
• C (Consistency - 一致性): 事务写入的数据必须符合数据库的所有约束（如唯一索引、Schema 验证等）。
• I (Isolation - 隔离性): MongoDB 使用快照隔离（Snapshot Isolation）。
  • 在事务提交之前，外部读取操作看不到事务内的修改。
  • 事务内的读取操作看到的是事务开始时的数据快照。
• D (Durability - 持久性): 通过 Write Concern（写关注）机制保证。通常建议在事务中使用 w: "majority"（大多数节点确认）加上开启 Journal 日志，以确保即使节点宕机数据也不会丢失。

3. 使用限制与最佳实践

虽然 MongoDB 支持事务，但官方和社区通常建议不要像在关系型数据库那样滥用事务。

• 性能开销： 多文档事务会带来性能损耗（协调锁、日志开销等）。
• 数据模型优先： 在 MongoDB 中，合理的数据建模（Denormalization/嵌入式设计） 仍然是首选。如果你发现自己频繁需要跨多个集合的事务，可能意味着你的数据模型设计得像关系型数据库，而没有利用 MongoDB 的文档特性。
• 事务限制：
  • 默认事务执行时间限制为 60 秒（可配置）。
  • 事务修改的数据量受限于 Oplog 的大小条目限制（虽然在 4.2+ 中已大幅放宽，但仍需注意超大事务）。
  • 不能在事务中进行创建集合、创建索引等 DDL 操作（通常只用于 CRUD）。

总结

MongoDB 现在的确是一个支持 ACID 事务的数据库。 它可以处理复杂的金融级交易场景，但为了获得最佳性能，仍应优先利用其文档模型的“单文档原子性”优势，将多文档事务作为处理复杂业务逻辑的辅助工具。