@DataJpaTest中一级缓存存在实体仍执行SQL查询的原因探究

关键原因拆解 #

• @BeforeEach与测试方法的事务边界不重合：
  即便测试类标注了@Transactional，Spring Test框架中@BeforeEach方法的执行逻辑是在测试方法的事务启动前完成的。这意味着你在@BeforeEach里保存实体的操作，是在一个独立的临时事务中执行并提交的，并不会进入测试方法后续开启的事务一级缓存。测试方法运行时，当前事务的缓存是空的，调用查询方法自然会触发数据库SQL。
• 查询方法的实现逻辑绕过一级缓存：
  如果memberQueryRepository.findMemberByEmail是以下情况，会直接跳过JPA一级缓存：
  • 使用原生SQL查询，JPA无法将这类查询与一级缓存关联；
  • 使用JPQL但只做投影查询（比如只查询email字段而非完整实体），这种场景不会加载实体到一级缓存，也不会从缓存读取；
  • 自定义查询未添加缓存提示，比如没有配置@QueryHints({@QueryHint(name = HINT_CACHEABLE, value = "true")})，部分场景下JPA不会触发缓存检查。
• 两次SQL的触发场景：
  日志里的两次select，一次可能是@BeforeEach中保存实体时，ORM框架的隐式验证（比如检查主键唯一性）；另一次则是测试方法中findMemberByEmail的主动查询——因为当前事务缓存中没有目标实体，只能直接查库。

快速验证方向 #

• 打印事务ID：在@BeforeEach和测试方法中分别打印TransactionSynchronizationManager.getCurrentTransactionId()，会看到两个不同的ID，证明两者不在同一事务；
• 修改查询方法：把JPQL改为加载完整实体（select m from Member m where m.email = ?1），再测试是否还触发SQL；
• 调整保存时机：把实体保存逻辑移到测试方法内部，再调用查询，此时一级缓存会生效，不会触发SQL。

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