Spring MongoDB中@Transactional(readOnly = true)的作用及相关疑问

1. 你的理解是否正确？ #

完全正确，补充几个细节帮你更清晰：

• MongoDB使用WiredTiger存储引擎时，事务的隔离级别确实固定为快照隔离（Snapshot Isolation），所有事务内的读写都基于事务启动时的数据库快照。
• 当你在Spring中使用@Transactional(readOnly = true)时，会开启一个只读事务：事务启动时创建快照，整个事务周期内的所有读操作都会复用这个快照，确保跨多个读操作的视图一致性（比如连续读多个文档，都是同一时间点的状态）。
• 不使用事务注解时，单条读操作的一致性由readConcern参数控制：
  • 比如默认的readConcern: local，保证读操作能看到已提交的本地节点数据；
  • 配置readConcern: snapshot时，单读操作也会基于一个快照，但这个快照是针对单操作的，无法跨多个读操作保持一致。

2. Spring MongoDB开发者是否常用@Transactional(readOnly=true)做只读操作？ #

分场景来看：

• 用的场景：当需要跨多个读操作的一致数据视图时（比如先读用户信息，再读该用户的订单列表，要求两者是同一时间点的状态，避免中间数据被修改），开发者会开启只读事务。
• 不用的场景：如果只是单条读操作（比如根据ID查单个文档），几乎不会用这个注解——直接通过readConcern配置一致性更轻量，没必要额外引入事务开销。

多数开发者会遵循「按需使用」原则，只有在需要多操作一致性时才启用只读事务。

3. 该注解是否会影响性能？ #

会有一定的性能开销，主要体现在：

• 事务启动时需要创建并维护快照，WiredTiger的快照会占用内存资源，事务持续时间越长，快照保留的时间越久，可能延迟旧数据的清理（影响存储层的复用效率）。
• 事务会占用MongoDB的事务槽资源（尤其是分片集群环境），大量并发只读事务可能会挤占可用于写事务的槽位。
• 单条读操作的情况下，开启事务的开销会比直接执行读操作明显更高，完全没必要。

但如果是需要跨多操作一致读的场景，这个开销是为了保证一致性必须付出的成本，属于合理权衡。

内容的提问来源于stack exchange，提问作者backtony