Java通过Hibernate查询无结果，SQL Developer正常，编辑条目后恢复？

这种情况我之前踩过好几个坑，太懂这种明明SQL没问题但Hibernate就是抽风的憋屈了！咱们一步步拆解可能的原因和解决办法：

1. Hibernate一级缓存（Session缓存）在搞鬼 #

Hibernate的Session会自动缓存已经查询过的实体，如果你之前在同一个Session里查过这条记录（当时可能不存在或者是旧值），后续的查询会直接从缓存取，根本不会去碰数据库。而你在SQL Developer修改数据后，要么Session缓存被自动失效，要么你重新获取了新Session，所以就能查到最新值了。

解决办法：

• 如果必须在同一个Session里获取最新数据，调用session.refresh(targetEntity)强制刷新指定实体；
• 或者用session.clear()清空当前Session的缓存，但注意这会清除所有缓存的实体，要谨慎使用；
• 尽量让查询操作在新Session中执行，比如Spring环境下，给查询方法配置@Transactional(propagation = Propagation.REQUIRES_NEW)开启新事务。

2. 事务隔离级别导致的快照读问题 #

如果你的Java应用事务隔离级别设得比较高（比如REPEATABLE READ），在事务开启后数据库会生成数据快照，这时候你在SQL Developer修改的数据，当前事务内是看不到的。而修改后重新执行查询，大概率是因为之前的事务已经提交，新事务能读到最新的数据快照。

解决办法：

• 检查事务配置，比如Spring中@Transactional的isolation属性，是否设置了合适的级别；
• 如果需要实时获取最新数据，把查询操作放在独立的只读短事务中，或者将隔离级别调整为READ COMMITTED。

3. 二级缓存未及时更新 #

如果你的项目启用了Hibernate二级缓存，手动在SQL Developer修改数据库是不会触发缓存更新的，所以Java查询还是会拿到旧的缓存数据（甚至是null）。而你修改VERSION列（乐观锁字段）时，可能刚好触发了缓存的失效机制，后续查询就能拿到新数据了。

解决办法：

• 检查二级缓存的实体缓存策略，确保配置正确；
• 对于手动修改数据库的场景，手动清除对应实体的缓存：sessionFactory.getCache().evictEntityRegion(YourTargetEntity.class)；
• 启用缓存自动刷新机制，或者依赖乐观锁字段（@Version注解）来自动触发缓存失效。

4. 参数绑定的隐形问题 #

有时候看起来SQL完全一样，但Hibernate的参数绑定可能藏着细节差异：比如日期参数的时区不一致、字符串参数带隐形空格、数字类型被转成字符串匹配等，都会导致查不到数据。

解决办法：

• 开启Hibernate的SQL日志，对比实际执行的SQL和参数值：

  # Spring Boot项目在application.properties中添加
  logging.level.org.hibernate.SQL=DEBUG
  logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE
  

• 仔细核对参数的类型、值是否和SQL Developer中完全一致，比如日期的格式、字符串的大小写/空格等。

5. 乐观锁字段的意外干扰 #

你提到修改VERSION列后就能查到，有可能你的查询条件里不小心包含了VERSION字段，或者缓存中的实体VERSION值和数据库不一致，导致查询被过滤掉了。

解决办法：

• 检查你的HQL/Criteria查询语句，确认是否误加了VERSION作为查询条件；
• 确保实体类上的@Version注解正确应用在VERSION字段上，配置没有出错。

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