Spring 只读事务面试详解

只读事务是 @Transactional 的一个属性，看起来简单，但面试中能问出很多深度问题。很多人只知道 readOnly = true 能优化查询，但说不清楚它到底优化了什么、底层怎么实现的、什么时候会失效。下面从面试角度把这个问题讲透。

一、基础概念

什么是只读事务？

@Transactional(readOnly = true) 表示这个事务只执行读操作，不会修改数据。它是 @Transactional 的一个属性，默认值是 false。

java 复制代码

@Transactional(readOnly = true)
public List<User> findAll() {
    return userMapper.selectAll();
}

为什么需要只读事务？

提示数据库和框架，这个事务不会写数据，可以做针对性优化。
防止误操作，在只读事务中执行写操作可能报错。
减少不必要的锁和日志开销，提升查询性能。

二、面试常问：只读事务到底优化了什么？

这是最核心的问题。很多人答"提升性能"，但说不清具体优化点。

1. MySQL InnoDB 层面的优化

在 MySQL InnoDB 中，只读事务会：

不分配事务 ID（TRX_ID）：普通事务在第一次写操作时会分配一个递增的事务 ID，只读事务不需要，减少了全局事务 ID 分配的开销。
减少 undo log 的维护：只读事务不需要回滚，不需要记录 undo log，减少了日志写入。
使用一致性读（Consistent Read）：只读事务通过 MVCC 快照读，不加锁，不阻塞其他事务。

2. JDBC 驱动层面

Connection.setReadOnly(true) 会传递给数据库驱动。不同数据库驱动有不同处理：

MySQL ：驱动会发送 SET SESSION TRANSACTION READ ONLY，将当前会话标记为只读。
Oracle：设置只读事务后，Oracle 会使用更高效的读一致性机制。
PostgreSQL：设置为只读事务后，数据库会拒绝写操作。

3. Spring 层面

Spring 把 readOnly 传递给 TransactionDefinition，事务管理器根据这个标记决定是否调用 Connection.setReadOnly(true)。在 DataSourceTransactionManager 中：

java 复制代码

// AbstractPlatformTransactionManager（简化）
if (definition.isReadOnly()) {
    con.setReadOnly(true);
}

4. Hibernate/JPA 层面

在 JPA 中，只读事务会：

跳过脏检查（Dirty Checking）：Hibernate 不需要在事务提交时对比实体快照，减少内存和 CPU 开销。
不维护持久化上下文的一级缓存快照。
设置 FlushMode.MANUAL，不自动 flush。

这一点在 JPA 场景下优化效果明显，但在 MyBatis 中不存在脏检查，优化主要体现在数据库层面。

三、面试常问：只读事务能阻止写操作吗？

答案：不一定。

readOnly = true 是一种提示，不是强制约束。是否能阻止写操作取决于数据库实现：

数据库	行为
MySQL InnoDB	只读事务中执行写操作会报错 `Cannot execute statement in a READ ONLY transaction`
Oracle	只读事务中执行写操作会报错
PostgreSQL	只读事务中执行写操作会报错
某些数据库	可能静默执行，不报错

所以不能依赖只读事务来保证安全。如果需要严格禁止写操作，应该在代码层面做校验，或使用数据库账号权限控制。

面试追问：那为什么还要用只读事务？

因为：

大多数数据库会阻止，能起到防护作用。
提示数据库做优化，减少开销。
代码可读性更好，明确表达这个方法只读。

四、面试常问：只读事务的传播行为影响

只读事务的传播行为有一个特殊规则：

如果当前已有事务，只读标记不会覆盖当前事务的读写属性。

java 复制代码

@Transactional(readOnly = false)
public void outer() {
    // 外层事务是读写事务
    innerService.query();  // 内层声明 readOnly = true
}

@Transactional(readOnly = true)
public void query() {
    // 虽然是 REQUIRED，加入外层事务
    // 但外层事务是读写的，内层不会强制变成只读
}

原因：REQUIRED 传播行为下，内层方法加入外层事务，事务属性由外层决定。内层的 readOnly = true 只在新建事务时生效。

如果内层用 REQUIRES_NEW，会新建独立事务，此时 readOnly = true 会生效。

java 复制代码

@Transactional(propagation = Propagation.REQUIRES_NEW, readOnly = true)
public void query() {
    // 新建独立只读事务
}

五、面试常问：只读事务与查询性能

问：只读事务能让查询变快吗？

答：能，但有前提。

在 MySQL InnoDB 中：只读事务减少了事务 ID 分配和 undo log 维护，对高频查询有提升，但提升幅度有限。
在 JPA/Hibernate 中：跳过脏检查，优化明显，尤其查询大量实体时。
在 MyBatis 中：没有脏检查，优化主要来自数据库层面，效果相对小。
如果查询本身没有写操作：不加只读事务，性能差异不大。

真正的性能提升来自：

数据库层面的读一致性优化。
减少锁竞争（只读事务不加锁）。
框架层面跳过不必要的检查。

不要指望只读事务能带来数量级的性能提升，它更多是一种规范和安全保障。

六、面试常问：只读事务能用在哪些方法上

方法类型	是否推荐只读事务
单个查询	可以加，但收益有限
多个查询组合	推荐，保证读一致性
查询 + 计算	推荐
查询 + 写操作	禁止
批量查询	推荐
报表统计	推荐

典型场景：

java 复制代码

// 推荐：多个查询需要读一致性
@Transactional(readOnly = true)
public OrderDetail getOrderDetail(Long orderId) {
    Order order = orderDao.findById(orderId);
    List<OrderItem> items = orderItemDao.findByOrderId(orderId);
    User user = userDao.findById(order.getUserId());
    return new OrderDetail(order, items, user);
}

这个场景中，三个查询需要在同一个一致性快照下执行，只读事务保证了读一致性。

七、面试常问：只读事务的坑

1. 内部调用失效

java 复制代码

@Service
public class UserService {
    
    public void doSomething() {
        this.query();  // ❌ 内部调用，只读事务不生效
    }
    
    @Transactional(readOnly = true)
    public List<User> query() {
        return userMapper.selectAll();
    }
}

内部调用不经过代理，@Transactional 不生效。

2. 只读事务中做写操作

java 复制代码

@Transactional(readOnly = true)
public void updateUser(User user) {
    userDao.update(user);  // ❌ MySQL 会报错
}

3. 只读事务与延迟加载

在 JPA 中，只读事务中访问懒加载关联可能报错，因为只读事务的 FlushMode 是 MANUAL。需要提前初始化关联，或关闭懒加载。

4. 只读事务不能解决脏读

只读事务保证的是"这个事务不写"，不保证"读到最新数据"。隔离级别才决定读的可见性。只读事务 + 低隔离级别，依然可能读到旧数据。

5. 嵌套事务中只读失效

java 复制代码

@Transactional
public void outer() {
    inner.query();  // REQUIRED 加入外层事务，只读失效
}

@Transactional(readOnly = true)
public void query() { }

外层是读写事务，内层 REQUIRED 加入后，只读标记被忽略。

八、面试实战：完整回答模板

面试官：说一下你对只读事务的理解。

回答框架：

定义：readOnly = true 是 @Transactional 的属性，表示事务中只执行读操作。
优化点 ：
- 数据库层面：不分配事务 ID、不维护 undo log、使用一致性读。
- 框架层面：JPA 跳过脏检查，MyBatis 优化较小。
- Spring 层面：调用 Connection.setReadOnly(true)。
限制：
- 不是强制约束，是否阻止写操作取决于数据库。
- REQUIRED 传播行为下，内层只读不覆盖外层读写。
- 内部调用失效。
适用场景：多个查询需要读一致性时使用，单个查询收益有限。
注意事项：不要依赖它做安全控制，不要在只读事务中写数据。

九、总结

面试问题	核心答案
只读事务优化了什么	数据库不分配事务 ID、不维护 undo log、使用一致性读；JPA 跳过脏检查
能阻止写操作吗	大多数数据库会报错，但不是强制约束
传播行为影响	REQUIRED 下内层只读不生效，REQUIRES_NEW 下生效
性能提升大吗	有限，JPA 场景明显，MyBatis 场景较小
什么时候用	多个查询需要读一致性时
常见坑	内部调用失效、嵌套失效、JPA 懒加载问题

只读事务是 Spring 事务属性中被低估的一个。面试中能答出"优化了什么"和"传播行为的影响"，就能体现你对事务的深入理解。记住核心：只读事务是提示，不是强制；优化有限，但规范和安全价值明确。