在 NHibernate Profiler 中，我观察到当我对关联使用预取时，在 HQL 查询中使用“左连接获取”或在标准查询中使用 .SetFetchMode() 时，查询不再缓存在查询缓存中。
事实上，据我所知，只有非常基本的查询被缓存。如果有人可以让我深入了解哪些查询被缓存，哪些不被缓存，我将标记为答案。
如果有任何不同，我正在使用 Memcached...。对于查询密集型系统，L2 缓存是否有更好的选择？
我发现这相当具有挑战性 - 如果我不使用预先加载，我会遇到 N+1 问题(但使用缓存)，如果我使用预先加载，我会从数据库中获取所有实体，但没有缓存。
似乎有一条很粗的分界线，两种策略都有性能改进，但两种策略都从另一种策略中抢走了性能。
如果有人可以深入了解这条“粗线”上的什么位置，我应该获得最佳性能，或者如何“使线变细”......我会非常谨慎并标记答案。
最佳答案
更新: 请看我的相关问题here .最重要的是，尝试使用 fetch="select"来避免加入已经在二级缓存中的对象。
我之前的回答(可能还有用)
查询缓存缓存从您的查询返回的标识符，而不是实际的对象
要正确使用它，你应该
- 使用占位符(? 或 :varName)
- 将查询缓存设置为 true(你做到了)
- 查询应该返回对象，而不是属性(
from Foo，而不是select foo.bar from Foo foo) - 返回的对象应该在二级缓存中，或者后续调用在同一个 hibernate session (同一个事务)中
为了澄清 #4，如果 2 个不同的事务使用完全相同的参数运行完全相同的(缓存的)查询并返回完全相同的对象，但它不在二级缓存中，仍然会发生数据库命中以获取实际的对象(可能是一个 select .. in )
查询缓存有两点用处——避免在同一事务中为非缓存项目的 HQL 查询重新访问数据库，并允许使用二级缓存对象进行 HQL 查询(自动用于加载或获取命令)
希望它能清除森林...
关于java - Hibernate 二级查询缓存不工作急切获取，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1752179/