Hibernate的数据加载

1. Session.get/load

区别：

1.1 如果未能发现符合条件的记录，get方法返回null，而load方法会抛出一个ObjectNotFoundException。

1.2 Load方法可返回实体的代理类实例，而get方法永远直接返回实体类。

1.3 load方法可以充分利用内部缓存和二级缓存中的现在数据，而get方法则仅仅在内部缓存中进行数据查找，如没有发现对应数据，将越过二级缓存，直接调用SQL完成数据读取。

2. Session.find/iterate

查询性能往往是一系统性能表现的一个重要方面。相对数据库更新、删除操作而言，查询机制的优劣很大程度上决定了系统的整体性能。

同样，这个领域，往往也存在最大的性能调整空间。对于同样的查询结果，不同的实现机制其性能差距可能超出我们大多数据 人的相像。

值得注意的是：Hibernate3 中，上述方法已经从Session接口中废除，统一由Query接口提供。find、iterate分别对应于Query.list和Query.iterate方法。

他们实现方式也不一样:find方法通过一条Select SQL实现了查询操作，而iterate方法，则执行三次Select SQL，第一次获取了所有符合条件的记录的ID，之后，再根据各个ID从库表中读取对应的记录，这是一个典型的N+1次查询问题。

既然如此，为何Hibernate还要提供iterate方法，而不是仅仅提供高效的find方法？

这个问题与Hibernate绑在机制密切相关。

----------

...find....

...iterate...

----------

以上情况，find方法将执行Select SQL从数据库中获得所有符合条件的记录并构造相应的实体对象，实体对象构建完毕之后，就将其纳入缓存。

这样，之后Iterate方法执行时，它首先执行一条Select SQL以获得所有符合查询条件的数据id,随即，iterate方法首先在本地缓存中根据ID查找对应的实体对象是否存在（类似Session.load方法），如果缓存中已经存在对应的数据，则直接以此数据对象作为查询结果，否则在执行相应的Select语句获得对应的库表记录（iterate方法如果执行了数据库读取操作并构建了完整的数据对象，也会将其查询结果纳入缓存）。

find方法实际上无法利用缓存，它对缓存只写不读。而iterate方法则可以充分发挥缓存带来的优势，如果目标数据只读或者读取相对较为频繁，通过这种机制可以大大减少性能上的损耗。

这是基于充分利用缓存以提升性能的考量。

同时，另一方面还有内存使用上的考量。

假设我们需要对海量的数据进行操作，那么,find方法将一次性获得所有记录并将其读入内存。假设有10万条符合条件的数据，那么这10万条数据会被一次性读入，无疑这将带来极大的内存消耗，此时很可能会触发OutOfMemoryError，从而导致系统异常。

3. Query Cache

Query Cache中保存了之前查询操作执行过的Select SQL,以及由此查询产生的查询结果集（包括查询对象的类型和ID）。

之后发生查询请求的时候，Hibernate会首先根据查询的SQL从Query Cache中检索，有执行过，则会提取出这个SQL的检索结果集，再根据结果集中的对象类型及ID，从缓存中取出对应的对象。

Query Cache中缓存的SQL及其结果集并非永完存在，当Hibernate发现此SQL对应的库发生了变动（UPDATE/INSERT/DELETE），会自动将Query Cache中对应表的SQL缓存废除。因此，Query Cache只在特定的情况下产生作用：

1. 完全相同的Select SQL重复执行。

2. 在两次查询之间，此Select SQL对应的库表没有发生过改变。

由于以上两个条件的严格限制，Query Cache在实际应用中的意义并没有我们相像中的那么重大，因此，Hibernate在默认情况下关闭了这个特性。

使用：

1. Hibernate配置文件：

<hibernate-configuration>

<session-factory>

......

<properry name="hibernate.cache.use_query_cache">true</property>

......

</session-factory>

</hibernate-configuration>

2. 应用

Query query = session.createQuery(hql).setInteger(0,20);

query.setCacheable(true);//如果有第二次查询，必须加这设置