大体上，对HIBERNATE性能调优的主要斟酌点以下:
? 数据库设计调剂
? HQL优化
? API的正确使用(如根据不同的业务类型选用不同的集合及查询API)
? 主配置参数(日志，查询缓存，fetch_size, batch_size等)
? 映照文件优化(ID生成策略，2级缓存，延迟加载，关联优化)
? 1级缓存的管理
? 针对2级缓存，还有许多独有的策略
? 事务控制策略。
1、 数据库设计
a) 下降关联的复杂性
b) 尽可能不使用联合主键
c) ID的生成机制，不同的数据库所提供的机制其实不完全1样
d) 适当的冗余数据，不过分寻求高范式
2、 HQL优化
HQL如果抛开它同HIBERNATE本身1些缓存机制的关联，HQL的优化技能同普通的SQL优化技能1样，可以很容易在网上找到1些经验之谈。
3、 主配置
a) 查询缓存，同下面讲的缓存不太1样，它是针对HQL语句的缓存，即完全1样的语句再次履行时可以利用缓存数据。但是，查询缓存在1个交易系统(数据变更频繁，查询条件相同的机率其实不大)中可能会起反作用:它会白白耗费大量的系统资源但却难以派上用处。
b) fetch_size，同JDBC的相干参数作用类似，参数其实不是越大越好，而应根据业务特点去设置
c) batch_size同上。
d) 生产系统中，切纪要关掉SQL语句打印。
4、 缓存
a) 数据库级缓存:这级缓存是最高效和安全的，但不同的数据库可管理的层次其实不1样，比如，在ORACLE中，可以在建表时指定将全部表置于缓存当中。
b) SESSION缓存:在1个HIBERNATE SESSION有效，这级缓存的可干预性不强，大多于HIBERNATE自动管理，但它提供清除缓存的方法，这在大批量增加/更新操作是有效的。比如，同时增加10万条记录，按常规方式进行，极可能会发现OutofMemeroy的异常，这时候可能需要手动清除这1级缓存:Session.evict和Session.clear
c) 利用缓存:在1个SESSIONFACTORY中有效，因此也是优化的重中之重，因此，各类策略也斟酌的较多，在将数据放入这1级缓存之前，需要斟酌1些条件条件:
i. 数据不会被第3方修改(比如，是不是有另外一个利用也在修改这些数据?)
ii. 数据不会太大
iii. 数据不会频繁更新(否则使用CACHE可能适得其反)
iv. 数据会被频繁查询
v. 数据不是关键数据(如触及钱，安全等方面的问题)。
缓存有几种情势，可以在映照文件中配置:read-only(只读，适用于很少变更的静态数据/历史数据)，nonstrict-read-write，read-write(比较普遍的情势，效力1般)，transactional(JTA中，且支持的缓存产品较少)
d) 散布式缓存:同c)的配置1样，只是缓存产品的选用不同，在目前的HIBERNATE中可供选择的不多，oscache, jboss cache，目前的大多数项目，对它们的用于集群的使用(特别是关键交易系统)都持守旧态度。在集群环境中，只利用数据库级的缓存是最安全的。
5、 延迟加载
a) 实体延迟加载:通过使用动态代理实现
b) 集合延迟加载:通过实现自有的SET/LIST，HIBERNATE提供了这方面的支持
c) 属性延迟加载:
6、 方法选用
a) 完成一样1件事，HIBERNATE提供了可供选择的1些方式，但具体使用甚么方式，可能用性能/代码都会有影响。显示，1次返回10万条记录(List/Set/Bag/Map等)进行处理，极可能致使内存不够的问题，而如果用基于游标(ScrollableResults)或Iterator的结果集，则不存在这样的问题。
b) Session的load/get方法，前者会使用2级缓存，而后者则不使用。
c) Query和list/iterator，如果去仔细研究1下它们，你可能会发现很多成心思的情况，2者主要区分(如果使用了Spring，在HibernateTemplate中对应find,iterator方法):
i. list只能利用查询缓存(但在交易系统中查询缓存作用不大)，没法利用2级缓存中的单个实体，但list查出的对象会写入2级缓存，但它1般只生成较少的履行SQL语句，很多情况就是1条(无关联)。
ii. iterator则可以利用2级缓存，对1条查询语句，它会先从数据库中找出所有符合条件的记录的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) 锁的选用:悲观锁(1般由具体的事务管理器实现)，对长事务效力低，但安全。乐观锁(1般在利用级别实现)，如在HIBERNATE中可以定义VERSION字段，明显，如果有多个利用操作数据，且这些利用不是用同1种乐观锁机制，则乐观锁会失效。因此，针对不同的数据应有不同的策略，同前面许多情况1样，很多时候我们是在效力与安全/准确性上找1个平衡点，不管如何，优化都不是1个纯技术的问题，你应当对你的利用和业务特点有足够的了解。
9、 批量操作
即便是使用JDBC，在进行大批数据更新时，BATCH与不使用BATCH有效力上也有很大的差别。我们可以通过设置batch_size来让其支持批量操作。
举个例子，要批量删除某表中的对象，如“delete Account”，打出来的语句，会发现HIBERNATE找出了所有ACCOUNT的ID，再进行删除，这主要是为了保护2级缓存，这样效力肯定高不了，在后续的版本中增加了bulk delete/update，但这也没法解决缓存的保护问题。也就是说，由于有了2级缓存的保护问题，HIBERNATE的批量操作效力其实不尽如人意!
从前面许多要点可以看出，很多时候我们是在效力与安全/准确性上找1个平衡点，不管如何，优化都不是1个纯技术的问题，你应当对你的利用和业务特点有足够的了解，1般的，优化方案应在架构设计期就基本肯定，否则可能致使没必要的返工，导致项目延期，而作为架构师和项目经理，还要面对开发人员可能的抱怨，必竟，我们对用户需求更改的控制力不大，但技术/架构风险是应当在早期意想到并制定好相干的对策。
还有1点要注意，利用层的缓存只是锦上添花，永久不要把它当救命稻草，利用的根基(数据库设计，算法，高效的操作语句，恰当API的选择等)才是最重要的。