Hibernate缓存搜索优化问询：非主键属性查询与索引构建机制

先明确Hibernate核心缓存的区别，再逐个解答你的问题：

1. 一级缓存（Session缓存） #

一级缓存本质就是个以主键为Key的Map，完全围绕主键组织数据。如果你的查询条件不含主键，一级缓存里根本做不到直接搜索——Hibernate会直接去查数据库，把返回的实体再塞进一级缓存里。JPA的@Index注解是用来生成数据库层面的索引，和一级缓存毫无关系，不会影响缓存内的检索逻辑。

2. 二级缓存与查询缓存 #

二级缓存默认也是按主键存储实体的，比如常用的Ehcache、Redis缓存实现都是如此。但要优化非主键条件的查询缓存，得靠查询缓存（Query Cache）：

• 开启查询缓存后，Hibernate会把查询语句+参数的哈希值作为Key，缓存查询结果对应的主键列表；
• 下次执行相同查询时，先从查询缓存里拿到主键，再去二级缓存加载实体，不用再查数据库。

但要注意：

• 查询缓存不是自动开启的，需要在配置里打开（比如hibernate.cache.use_query_cache=true），并且在查询时显式调用setCacheable(true)；
• JPA的@Index依然和缓存无关，它只作用于数据库，不会让Hibernate在缓存层面创建对应的索引。如果想在缓存里直接按非主键属性检索，得依赖缓存实现本身的特性（比如Ehcache的搜索API），或者自己扩展Hibernate的缓存策略，但这属于自定义操作，不是Hibernate的默认行为。

关于你的猜测 #

你的说法不完全准确：

• 如果没开启查询缓存，直接用非主键条件去搜实体缓存（一级/二级），确实不可行，因为实体缓存是按主键组织的，没有非主键的索引结构，没法快速定位；
• 但如果用了查询缓存，非主键条件的查询是可以利用缓存的，只是它缓存的是结果主键列表，而非直接按非主键属性索引实体。

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