Hibernate查询缓存失效求助：无法缓存Lookup Table数据

我来帮你排查这个缓存不生效反而拖慢查询的问题——你已经做了不少基础配置，但可能有些关键细节没到位，导致缓存没起作用还额外增加了开销。下面是几个需要重点检查和调整的方向：

1. 确认查询缓存的完整配置 #

你已经开启了use_query_cache=true，但还要确保查询本身被正确标记为可缓存：

• 如果你用的是Session.createQuery，一定要显式调用query.setCacheable(true)（仅session.setCacheable(true)可能不够，不同版本的Hibernate行为有差异）；
• 检查Ehcache配置文件中是否存在查询缓存的区域，默认是org.hibernate.cache.internal.StandardQueryCache，如果自定义了区域，要确保配置了合理的内存存储和过期时间（查找表数据稳定，过期时间可以设长一些）；
• 注意查询缓存的键是基于查询语句、参数、Hibernate方言等的哈希值，要保证每次执行的查询语句完全一致（比如避免拼接SQL字符串，用参数绑定），否则会生成不同的缓存键导致每次都查数据库。

2. 区分实体二级缓存和查询缓存的作用 #

你给实体加了@Cacheable和@Cache(readOnly, region="my region")，这是实体二级缓存，而查询缓存存储的是查询结果的ID列表——如果二级缓存没生效，查询缓存拿到ID后还是会去数据库逐个加载实体，这就是你看到的“每次查询数据库的每一行”的原因：

• 确保Hibernate配置中开启了二级缓存：hibernate.cache.use_second_level_cache=true（很多人会漏掉这个关键配置）；
• @Cache的usage设置要正确，查找表数据只读，用CacheConcurrencyStrategy.READ_ONLY是最优选择；
• 确认Ehcache配置文件中my region这个区域的配置正确，比如设置maxEntriesLocalHeap足够容纳所有查找表数据，避免缓存溢出。

3. 避免N+1查询陷阱 #

如果查找表实体有关联对象，即使开启了缓存，也可能因为关联对象未被缓存而触发N+1查询。解决方法：

• 查询时使用fetch join一次性加载关联实体，比如：

  session.createQuery("from LookupTable lt join fetch lt.relatedEntity").setCacheable(true).list();
  

• 给关联的实体也配置二级缓存，确保关联数据能从缓存中获取。

4. 验证缓存是否真的在工作 #

打开Hibernate的日志，设置org.hibernate.cache的日志级别为DEBUG，观察日志中是否有如下内容：

• Cache hit: region=my region, key=...：表示实体二级缓存命中；
• Cache hit: region=org.hibernate.cache.internal.StandardQueryCache, key=...：表示查询缓存命中；
  如果只有Cache miss，说明缓存根本没被写入或者键不匹配，需要进一步排查配置。

5. 查找表的简化缓存方案 #

对于数据量小、几乎不修改的查找表，其实可以跳过Hibernate的缓存机制，直接在应用启动时加载一次数据到本地缓存：

// 在应用初始化方法中执行
List<LookupTable> lookupList = session.createQuery("from LookupTable").list();
// 存入本地缓存，比如Guava Cache或Ehcache本地缓存
localCache.put("ALL_LOOKUP_DATA", lookupList);

后续下拉框直接从本地缓存取数据，完全避免数据库查询，效率更高也更简单。

内容的提问来源于stack exchange，提问作者Manthesh M R