1.抓取 优化
抓取是指Hibernate如何在关联关系之间进行导航的时候，Hibernate如何获取关联对象的策略，其主要定义了两个方面：如何抓取和何时抓取
1）如何抓取。
Hibernate3主要有两种种抓取方式，分别应用于对象关联实例(many-to-one、one-to-one)和对象关联集合(set、map等)，总共是四种变种
JOIN抓取： 通过在SELECT语句中使用OUTER JOIN来获得对象的关联实例或者关联集合）
SELECT抓取： 另外发送一条SELECT语句来抓取当前对象的关联实体和集合
在我的开发经历中，此处对性能的优化是比较有限的，并不值得过多关注
例：
A.应用于对象关联实例（默认是false）
<many-to-one name=".." outer-join="true/false/auto" .../>
B.应用于对象关联集合（默认是auto）
<set name=".." fetch="join/select" ... >
....
</set>
2）何时抓取
主要分为延迟加载和立即抓取，默认的情况下Hibernate3对对象关联实采用延迟加载，普通属性采用立即抓取，通过延迟加载和采用适当的抓取粒度，与不采用优化相比往往可以将性能提升数倍
立即抓取：当抓取宿主对象时，同时抓取其关联对象和关联集以及属性
延迟加载：当抓取宿主对象时，并不抓取其关联对象，而是当对其对象进行调用时才加载
例：
A.应用于对象关联实例（默认是延迟加载）
<many-to-one name=".." lazy="true/false" .../>
B.应用于对象关联集合（默认是延迟加载）
<set name=".." lazy="true/false" ... >
....
</set>
对于延迟加载，需要注意的时，对延迟对象的使用必须在Session关闭之前进行，Hibernate的 LazyInitalizationException往往就是由于在Session的生命期外使用了延迟加载的对象。当我们进行Web开发时，可以使用 OpenSessionInView模式，当请求开始时打开session，当请求响应结束时才关闭session，不过，在使用 OpenSessionInView模式时，需要注意如果响应时间比较长（业务比较复杂或者客户端是低速网络），将Session资源(也就是数据库的连接)占用太久的话可以会导致资源耗尽
3）抓取粒度
抓取粒度指的是对象在关联关系之间被导航时一次预先加载的数量，Hibernate程序的性能比较差往往就在于没有对抓取粒度仔细考虑，当加载一个列表并在列表中的每个对象中对其关联进行导航时，往往导致N+1条SQL语句查询。
例：
A.应用于对象关联实例（默认为1），注意，对对象关联实例的设 置是在被关联的对象之上的，譬如
class User
{
Group g;
}
那么抓取粒度应该在Group的配置文件之上，见下
<class name="Group" table="group" batch-size="..">
...
</class>
对该值并没有一个约定俗成的值，根据情况而定，如果被关联表数据比较少，则可以设置地小一些，3-20，如果比较大则可以设到30-50，注意的时候，并不是越多越好，当其值超过50之后，对性能并没有多大改善但却无谓地消耗内存
假设有如下例子：
List<User> users = query.list();
如果有20个User，并对这20个User及其Group进行遍历，如果不设置batch-size（即batch-size="1"），则在最糟糕的情况
下，需要1 + 20条SQL语句，如果设置batch-size="10"，则最好的情况下只需要1 + 2条SQL语句
B.应用于对象关联集合（默认为1）
<set name=".." batch-size="" ... >
....
</set>
2.二级缓存
Hibernate 对数据的缓存包括两个级：一级缓存，在Session的级别上进行，主要是对象缓存，以其id为键保存对象，在Session的生命期间存在；二级缓存，在SessionFactory的级别上进行，有对象缓存和查询缓存，查询缓存以查询条件为键保存查询结果，在SessionFactory的生命期间存在。默认地，Hibernate只启用一级缓存，通过正确地使用二级缓存，往往可以获得意想不到的性能。
1）对象缓存：
当抓取一个对象之后，Hiberate将其以id为键缓存起来，当下次碰到抓取id相同的对象时，可以使用如下配置
方法1：在缓存对象上配置
<class ...>
<cache useage="read-only/write/...." regions="group" />
</class>
useage 表示使用什么类型的缓存，譬如只读缓存、读写缓存等等（具体参见Hibernate参考指南），值得注意的时，有部分缓存在Hibernate的实现中不支持读写缓存，譬如JBossCache在Hibernate的实现中只是一种只读缓存，具体缓存实现对缓存类型的支持情况，可以参见 org.hibernate.cache包
regions表示缓存分块，大部分的缓存实现往往对缓存进行分块，该部分是可选的，详细参见各缓存实现
方法2：在hibernate.cfg.xml中配置
<cache class=".." useage=".." regions=".."/>
我认为第二种更好，可以统一管理
2)查询缓存
查询时候将查询结果以查询条件为键保存起来，需要配置如下
A.在hibernate.cfg.xml中配置（启用查询缓存）
<property name="hibernate.cache.use_query_cache">true</property> （前面的属性名可参见常量
org.hibernate.cfg.Enviroment.USE_QUERY_CACHE）
B.程序
query.setCacheable(true);
query.setCacheRegions(...);
需要注意的是,查询缓存与对象缓存要结合更有效,因为查询缓存仅缓存查询结果列表的主键数据
一般情况下在开发中，对一些比较稳定而又被频繁引用的数据，譬如数据字典之类的，将其进行二级缓存，对一些查询条件和查询数据变化不频繁而又常常被使用的查询，将其进行二级缓存。由于二级缓存是放在内存中，而且Hibernate的缓存不是弱引用缓存（WeekReference），所以注意不要将大块的数据放入其中，否则可能会被内存造成比较大的压力。
3.批量数据操作
当进行大批量数据操作（几万甚至几十几百万）时，需要注意两点，一，批量提交，二，及时清除不需要的一级缓存数据
1）所谓的批量提交，就是不要频繁使用session的flush，每一次进行flush，Hibernate将PO数据于数据库进行同步，对于海量级数据操作来说是性能灾难（同时提交几千条数据和提交一条数据flush一次性能差别可能会是几十倍的差异）。一般将数据操作放在事务中，当事务提交时 Hibernate自动帮你进行flush操作。
2）及时清除不需要的一级缓存数据：由于Hibernate默认采用一级缓存，而在 session的生命期间，所有数据抓取之后会放入一级缓存中，而当数据规模比较庞大时，抓取到内存中的数据会让内存压力非常大，一般分批操作数据，被一次操作之后将一级缓存清除，譬如
session.clear(User.class)
4.杂项
dynamic-insert，dynamic-update，动态插入和动态更新，指的是让Hibernate插入数据时仅插入非空数据，当修改数据时只修改变化的数据，譬如对于
class User
{
id
username
password
}
如果u.id=1, u.username="ayufox",u.password=null，那么如果不设置动态插入，则其sql语句是 insert into users(id, username, password) values (1, 'ayufox', ')，如果设置则其 sql语句是insert into users(username) valeus('ayufox')
在如上的情况下，如果修改 u.password='11'，那么如果不设置动态更新，则sql语句为update users set username='ayufox', password='11' where id = 1，如果设置则为update user set password='11' where d = 1
设置是在class的映射文件中，如下
<class name="User" table="users" dynamic-insert="true/false" dynamic-update="true/false" ...>
</class>
该设置对性能的提升比较有限
本文依照HIBERNATE帮助文档，一些网络书籍及项目经验整理而成，只提供要点和思路，具体做法可以留言探讨，或是找一些更详细更有针对性的资料。
初用HIBERNATE的人也许都遇到过性能问题，实现同一功能，用HIBERNATE与用JDBC性能相差十几倍很正常，如果不及早调整，很可能影响整个项目的进度。
大体上，对于HIBERNATE性能调优的主要考虑点如下:
? 数据库设计调整
? HQL优化
? API的正确使用(如根据不同的业务类型选用不同的集合及查询API)
? 主配置参数(日志，查询缓存，fetch_size, batch_size等)
? 映射文件优化(ID生成策略，二级缓存，延迟加载，关联优化)
? 一级缓存的管理
? 针对二级缓存，还有许多特有的策略
? 事务控制策略。
1、 数据库设计
a) 降低关联的复杂性
b) 尽量不使用联合主键
c) ID的生成机制，不同的数据库所提供的机制并不完全一样
d) 适当的冗余数据，不过分追求高范式
2、 HQL优化
HQL如果抛开它同HIBERNATE本身一些缓存机制的关联，HQL的优化技巧同普通的SQL优化技巧一样，可以很容易在网上找到一些经验之谈。
3、 主配置
a) 查询缓存，同下面讲的缓存不太一样，它是针对HQL语句的缓存，即完全一样的语句再次执行时可以利用缓存数据。但是，查询缓存在一个交易系统(数据变更频繁，查询条件相同的机率并不大)中可能会起反作用:它会白白耗费大量的系统资源但却难以派上用场。
b) fetch_size，同JDBC的相关参数作用类似，参数并不是越大越好，而应根据业务特征去设置
c) batch_size同上。
d) 生产系统中，切记要关掉SQL语句打印。
4、 缓存
a) 数据库级缓存:这级缓存是最高效和安全的，但不同的数据库可管理的层次并不一样，比如，在ORACLE中，可以在建表时指定将整个表置于缓存当中。
b) SESSION缓存:在一个HIBERNATE SESSION有效，这级缓存的可干预性不强，大多于HIBERNATE自动管理，但它提供清除缓存的方法，这在大批量增加/更新操作是有效的。比如，同时增加十万条记录，按常规方式进行，很可能会发现OutofMemeroy的异常，这时可能需要手动清除这一级缓存:Session.evict以及 Session.clear
c) 应用缓存:在一个SESSIONFACTORY中有效，因此也是优化的重中之重，因此，各类策略也考虑的较多，在将数据放入这一级缓存之前，需要考虑一些前提条件:
i. 数据不会被第三方修改(比如，是否有另一个应用也在修改这些数据?)
ii. 数据不会太大
iii. 数据不会频繁更新(否则使用CACHE可能适得其反)
iv. 数据会被频繁查询
v. 数据不是关键数据(如涉及钱，安全等方面的问题)。
缓存有几种形式，可以在映射文件中配置:read-only(只读，适用于很少变更的静态数据/历史数据)，nonstrict-read- write，read-write(比较普遍的形式，效率一般)，transactional(JTA中，且支持的缓存产品较少)
d) 分布式缓存:同c)的配置一样，只是缓存产品的选用不同，在目前的HIBERNATE中可供选择的不多，oscache, jboss cache，目前的大多数项目，对它们的用于集群的使用(特别是关键交易系统)都持保守态度。在集群环境中，只利用数据库级的缓存是最安全的。
5、 延迟加载
a) 实体延迟加载:通过使用动态代理实现
b) 集合延迟加载:通过实现自有的SET/LIST，HIBERNATE提供了这方面的支持
c) 属性延迟加载:
6、 方法选用
a) 完成同样一件事，HIBERNATE提供了可供选择的一些方式，但具体使用什么方式，可能用性能/代码都会有影响。显示，一次返回十万条记录(List /Set/Bag/Map等)进行处理，很可能导致内存不够的问题，而如果用基于游标(ScrollableResults)或Iterator的结果集，则不存在这样的问题。
b) Session的load/get方法，前者会使用二级缓存，而后者则不使用。
c) Query和list/iterator，如果去仔细研究一下它们，你可能会发现很多有意思的情况，二者主要区别(如果使用了Spring，在HibernateTemplate中对应find,iterator方法):
i. list只能利用查询缓存(但在交易系统中查询缓存作用不大)，无法利用二级缓存中的单个实体，但list查出的对象会写入二级缓存，但它一般只生成较少的执行SQL语句，很多情况就是一条(无关联)。
ii. iterator则可以利用二级缓存，对于一条查询语句，它会先从数据库中找出所有符合条件的记录的ID，再通过ID去缓存找，对于缓存中没有的记录，再构造语句从数据库中查出，因此很容易知道，如果缓存中没有任何符合条件的记录，使用iterator会产生N+1条SQL语句(N为符合条件的记录数)
iii. 通过iterator，配合缓存管理API，在海量数据查询中可以很好的解决内存问题，如:
while(it.hasNext()){
YouObject object = (YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
}
如果用list方法，很可能就出OutofMemory错误了。
iv. 通过上面的说明，我想你应该知道如何去使用这两个方法了。
7、 集合的选用
在HIBERNATE 3.1文档的“19.5. Understanding Collection performance”中有详细的说明。
8、 事务控制
事务方面对性能有影响的主要包括:事务方式的选用，事务隔离级别以及锁的选用
a) 事务方式选用:如果不涉及多个事务管理器事务的话，不需要使用JTA，只有JDBC的事务控制就可以。
b) 事务隔离级别:参见标准的SQL事务隔离级别
c) 锁的选用:悲观锁(一般由具体的事务管理器实现)，对于长事务效率低，但安全。乐观锁(一般在应用级别实现)，如在HIBERNATE中可以定义 VERSION字段，显然，如果有多个应用操作数据，且这些应用不是用同一种乐观锁机制，则乐观锁会失效。因此，针对不同的数据应有不同的策略，同前面许多情况一样，很多时候我们是在效率与安全/准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解。
9、 批量操作
即使是使用JDBC，在进行大批数据更新时，BATCH与不使用BATCH有效率上也有很大的差别。我们可以通过设置batch_size来让其支持批量操作。
举个例子，要批量删除某表中的对象，如“delete Account”，打出来的语句，会发现HIBERNATE找出了所有ACCOUNT的ID，再进行删除，这主要是为了维护二级缓存，这样效率肯定高不了，在后续的版本中增加了bulk delete/update，但这也无法解决缓存的维护问题。也就是说，由于有了二级缓存的维护问题，HIBERNATE的批量操作效率并不尽如人意!
从前面许多要点可以看出，很多时候我们是在效率与安全/准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解，一般的，优化方案应在架构设计期就基本确定，否则可能导致没必要的返工，致使项目延期，而作为架构师和项目经理，还要面对开发人员可能的抱怨，必竟，我们对用户需求更改的控制力不大，但技术/架构风险是应该在初期意识到并制定好相关的对策。
还有一点要注意，应用层的缓存只是锦上添花，永远不要把它当救命稻草，应用的根基(数据库设计，算法，高效的操作语句，恰当API的选择等)才是最重要的。
Hibernate的缓存***********************************
1、首先设置EhCache，建立配置文件ehcache.xml，默认的位置在class-path，可以放到你的src目录下：
- ＜?xml version="1.0" encoding="UTF-8"?＞
- ＜ehcache＞
- ＜diskStore path="java.io.tmpdir"/＞
- ＜defaultCache
- maxElementsInMemory="10000" ＜!-- 缓存最大数目 --＞
- eternal="false" ＜!-- 缓存是否持久 --＞
- overflowToDisk="true" ＜!-- 是否保存到磁盘，当系统当机时--＞
- timeToIdleSeconds="300" ＜!-- 当缓存闲置n秒后销毁 --＞
- timeToLiveSeconds="180" ＜!-- 当缓存存活n秒后销毁--＞
- diskPersistent="false"
- diskExpiryThreadIntervalSeconds= "120"/＞
- ＜/ehcache＞
2、在Hibernate配置文件中设置：
- ＜!-- 设置Hibernate的缓存接口类，这个类在Hibernate包中 --＞
- ＜property name="cache.provider_class"＞org.hibernate.cache.EhCacheProvider＜/property＞
- ＜!-- 是否使用查询缓存 --＞
- ＜property name="hibernate.cache.use_query_cache"＞true＜/property＞
- 如果使用spring调用Hibernate的sessionFactory的话，这样设置：
- ＜!--HibernateSession工厂管理 --＞
- ＜bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"＞
- ＜property name="dataSource"＞
- ＜ref bean="datasource" /＞
- ＜/property＞
- ＜property name="hibernateProperties"＞
- ＜props＞
- ＜prop key="hibernate.dialect"＞org.hibernate.dialect.Oracle9Dialect＜/prop＞
- ＜prop key="connection.provider_class"＞org.hibernate.connection.C3P0ConnectionProvider＜/prop＞
- ＜prop key="hibernate.show_sql"＞true＜/prop＞
- ＜prop key="hibernate.cache.use_query_cache"＞true＜/prop＞
- ＜prop key="hibernate.cache.provider_class"＞org.hibernate.cache.EhCacheProvider＜/prop＞
- ＜/props＞
- ＜/property＞
- ＜property name="mappingDirectoryLocations"＞
- ＜list＞
- ＜value＞/WEB-INF/classes/cn/rmic/manager/hibernate/＜/value＞
- ＜/list＞
- ＜/property＞
- ＜/bean＞
说明一下：如果不设置“查询缓存”，那么hibernate只会缓存使用load()方法获得的单个持久化对象，如果想缓存使用 findall()、list()、Iterator()、createCriteria()、createQuery()等方法获得的数据结果集的话，就需要设置
hibernate.cache.use_query_cache true 才行
3、在Hbm文件中添加＜cache usage="read-only"/＞
4、如果需要“查询缓存”，还需要在使用Query或Criteria()时设置其setCacheable(true);属性
5、实践出真知，给一段测试程序，如果成功的话第二次查询时不会读取数据库
- package cn.rmic.hibernatesample;
- import java.util.List;
- import org.hibernate.CacheMode;
- import org.hibernate.Criteria;
- import org.hibernate.Query;
- import org.hibernate.Session;
- import cn.rmic.hibernatesample.hibernate.HibernateSessionFactory;
- import cn.rmic.manager.po.Resources;
- public class testCacheSelectList ...{
- /** *//**
- * @param args
- */
- public static void main(String[] args) ...{
- // TODO Auto-generated method stub
- Session s=HibernateSessionFactory.getSession();
- Criteria c=s.createCriteria(Resources.class);
- c.setCacheable(true);
- List l=c.list();
- // Query q=s.createQuery("From Resources r")
- // .setCacheable(true)
- // .setCacheRegion("frontpages") ;
- // List l=q.list();
- Resources resources=(Resources)l.get(0);
- System.out.println("-1-"+resources.getName());
- HibernateSessionFactory.closeSession();
- try ...{
- Thread.sleep(5000);
- } catch (InterruptedException e) ...{
- // TODO Auto-generated catch block
- e.printStackTrace();
- }
- s=HibernateSessionFactory.getSession();
- c=s.createCriteria(Resources.class);
- c.setCacheable(true);
- l=c.list();
- // q=s.createQuery("From Resources r").setCacheable(true)
- // .setCacheRegion("frontpages");
- // l=q.list();
- resources=(Resources)l.get(0);
- System.out.println("-2-"+resources.getName());
- HibernateSessionFactory.closeSession();
- }
- }
inverse=false(default)
用于单向one-to-many关联
parent.getChildren().add(child) // insert child
parent.getChildren().delete(child) // delete child
inverse=true
用于双向one-to-many关联
child.setParent(parent); session.save(child) // insert child
session.delete(child)
在分层结构的体系中
parentDao, childDao对于CRUD的封装导致往往直接通过session接口持久化对象，而很少通过关联对象可达性
二。 one-to-many关系
单向关系还是双向关系？
parent.getChildren().add(child)对集合的触及操作会导致lazy的集合初始化，在没有对集合配置二级缓存的情况下，应避免此类操作
select * from child where parent_id = xxx;
性能口诀：
1. 一般情况下避免使用单向关联，尽量使用双向关联
2. 使用双向关联，inverse=“true”
3. 在分层结构中通过DAO接口用session直接持久化对象，避免通过关联关系进行可达性持久化
三。many-to-one关系
单向many-to-one表达了外键存储方
灵活运用many-to-one可以避免一些不必要的性能问题
many-to-one表达的含义是：0..n : 1，many可以是0，可以是1，也可以是n，也就是说many-to-one可以表达一对多，一对一，多对一关系
因此可以配置双向many-to-one关系，例如：
1. 一桌四人打麻将，麻将席位和打麻将的人是什么关系？是双向many-to-one的关系
四。one-to-one
通过主键进行关联
相当于把大表拆分为多个小表
例如把大字段单独拆分出来，以提高数据库操作的性能
Hibernate的one-to-one似乎无法lazy，必须通过bytecode enhancement
五。集合List/Bag/Set
one-to-many
1. List需要维护index column，不能被用于双向关联，必须inverse=“false”，被谨慎的使用在某些稀有的场合
2. Bag/Set语义上没有区别
3. 我个人比较喜欢使用Bag
many-to-many
1. Bag和Set语义有区别
2。 建议使用Set
六。集合的过滤
1. children = session.createFilter(parent.getChildren(), “where this.age > 5 and this.age < 10”).list()
针对一对多关联当中的集合元素非常庞大的情况，特别适合于庞大集合的分页：
session.createFilter(parent.getChildren(),“”).setFirstResult(0).setMaxResults(10).list();
在hibernate 中用 super.getSession().createFilter( , )
七。继承关系当中的隐式多态
HQL: from Object
1. 把所有数据库表全部查询出来
2. polymorphism=“implicit”(default)将当前对象，和对象所有继承子类全部一次性取出
3. polymorphism=“explicit”，只取出当前查询对象
八。Hibernate二级缓存
著名的n+1问题：from Child，然后在页面上面显示每个子类的父类信息，就会导致n条对parent表的查询：
select * from parent where id = ?
.......................
select * from parent where id = ?
解决方案
1. eager fetch
2. 二级缓存
九。inverse和二级缓存的关系
当使用集合缓存的情况下：
1. inverse=“false”，通过parent.getChildren()来操作，Hibernate维护集合缓存
2. inverse=“true”，直接对child进行操作，未能维护集合缓存！导致缓存脏数据
3. 双向关联，inverse=“true”的情况下应避免使用集合缓存
十。Hibernate二级缓存是提升web应用性能的法宝
OLTP类型的web应用，由于应用服务器端可以进行群集水平扩展，最终的系统瓶颈总是逃不开数据库访问；
哪个框架能够最大限度减少数据库访问，降低数据库访问压力， 哪个框架提供的性能就更高；针对数据库的缓存策略：
1. 对象缓存：细颗粒度，针对表的记录级别，透明化访问，在不改变程序代码的情况下可以极大提升web应用的性能。对象缓存是ORM的制胜法宝。
2. 对象缓存的优劣取决于框架实现的水平，Hibernate是目前已知对象缓存最强大的开源ORM
3. 查询缓存：粗颗粒度，针对查询结果集，应用于数据实时化要求不高的场合
十一。应用场合决定了系统架构
一、是否需要ORM
Hibernate or iBATIS？
二、采用ORM决定了数据库设计
Hibernate：
倾向于细颗粒度的设计，面向对象，将大表拆分为多个关联关系的小表，消除冗余column，通过二级缓存提升性能（DBA比较忌讳关联关系的出现，但是 ORM的缓存将突破关联关系的性能瓶颈）；Hibernate的性能瓶颈不在于关联关系，而在于大表的操作
iBATIS：
倾向于粗颗粒度设计，面向关系，尽量把表合并，通过表column冗余，消除关联关系。无有效缓存手段。iBATIS的性能瓶颈不在于大表操作，而在于关联关系。
总结：
性能口诀
1、使用双向一对多关联，不使用单向一对多
2、灵活使用单向多对一关联
3、不用一对一，用多对一取代
4、配置对象缓存，不使用集合缓存
5、一对多集合使用Bag，多对多集合使用Set
6、继承类使用显式多态
7、表字段要少，表关联不要怕多，有二级缓存撑腰
最近开始留意项目中的Hibernate的性能问题，希望可以抽出时间学习一下hiberante的性能优化。主要是对数据库连接池技术、hibernate二级缓存、hibernate的配置优化等问题进行学习！
1.关联关系：
普通的关联关系：是不包括一个连接表，也就是中间表如：
create table Person(personId bigint not null primary key,addressId bigint not null)
create table Address(addressId bigint not null primary key)
也就是不会还有一个关系表如：
create table Person(personId bigint not null primary key)
create table Address(addressId bigint not null primary key)
create table PersonAddress(personId bigint not null,ddressId bigint not null primary key)
单向many-to-one关联是最常见的，而单向one-to-many是不常见的
2. inner join (内连接)
left (outer) join （左外连接）
right (outer) join (右外连接)
full join (全连接，并不常用)
3.小技巧：
统计结果数目：
(Integer)session.iterator("select count(*) from ..").next()).intValue();
根据一个集合大小来排序：
select user.id,user.name
from User as user.name
left join user.messages msg
group by user.id,user.name
having count(msg)>=1
2) 对大数据量查询时，慎用 list() 或者 iterator() 返回查询结果，
1. 使用 List() 返回结果时， Hibernate 会所有查询结果初始化为持久化对象，结果集较大时，会占用很多的处理时间。
2. 而使用 iterator() 返回结果时，在每次调用 iterator.next() 返回对象并使用对象时， Hibernate 才调用查询将对应的对象初始化，对于大数据量时，每调用一次查询都会花费较多的时间。当结果集较大，但是含有较大量相同的数据，或者结果集不是全部都会使用时，使用 iterator() 才有优势。
3. 对于大数据量，使用 qry.scroll() 可以得到较好的处理速度以及性能。而且直接对结果集向前向后滚动。
3) 对于关联操作， Hibernate 虽然可以表达复杂的数据关系，但请慎用，使数据关系较为简单时会得到较好的效率，特别是较深层次的关联时，性能会很差。
4) 对含有关联的 PO （持久化对象）时，若 default-cascade="all" 或者 “save-update” ，新增 PO 时，请注意对 PO 中的集合的赋值操作，因为有可能使得多执行一次 update 操作。
5) 在一对多、多对一的关系中，使用延迟加载机制，会使不少的对象在使用时 才 会初始化，这样可使得节省内存空间以及减少数据库的负荷，而且若 PO 中的集合没有被使用时，就可减少互数据库的交互从而减少处理时间。
8) Hibernate 可以通过设置 hibernate.jdbc.fetch_size ， hibernate.jdbc.batch_size 等属性，对 Hibernate 进行优化。
14) Hibernate 支持两种锁机制：即通常所说的“悲观锁（ Pessimistic Locking ）”和“乐观锁（ Optimistic Locking ）”。 悲观锁带来 数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题.乐观锁机制避免了长事务中的数据库加锁开销,大大提升了大并发量下的系统整体性能表现。