如何优化Hibernate

1、数据库设计a) 降低关联的复杂性b) 尽量不使用联合主键c) ID的生成机制，不同的数据库所提供的机制并不完全一样d) 适当的冗余数据，不过分追求高范式

3、主配置a) 查询缓存，同下面讲的缓存不太一样，它是针对HQL语句的缓存，即完全一样的语句再次执行时可以利用缓存数据。但是，查询缓存在一个交易系统(数据变更频繁，查询条件相同的机率并不大)中可能会起反作用:它会白白耗费大量的系统资源但却难以派上用场。b) fetch_size，同JDBC的相关参数作用类似，参数并不是越大越好，而应根据业务特征去设置c) batch_size同上。d) 生产系统中，切记要关掉SQL语句打印。

5、延迟加载a) 实体延迟加载:通过使用动态代理实现b) 集合延迟加载:通过实现自有的SET/LIST，Hibernate提供了这方面的支持c) 属性延迟加载:

7、集合的选用在Hibernate 3.1文档的“19.5. Understanding Collection performance”中有详细的说明。

9、批量操作即使是使用Jdbc，在进行大批数据更新时，BATCH与不使用BATCH有效率上也有很大的差别。我们可以通过设置batch_size来让其支持批量操作。举个例子，要批量删除某表中的对象，如“delete Account”，打出来的语句，会发现HIBERNATE找出了所有ACCOUNT的ID，再进行删除，这主要是为了维护二级缓存，这样效率肯定高不了，在后续的版本中增加了bulk delete/update，但这也无法解决缓存的维护问题。也就是说，由于有了二级缓存的维护问题，HIBERNATE的批量操作效率并不尽如人意!

10、从前面许多要点可以看出，很多时候我们是在效率与安全/准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解，一般的，优化方案应在架构设计期就基本确定，否则可能导致没必要的返工，致使项目延期，而作为架构师和项目经理，还要面对开发人员可能的抱怨，必竟，我们对用户需求更改的控制力不大，但技术/架构风险是应该在初期意识到并制定好相关的对策。还有一点要注意，应用层的缓存只是锦上添花，永远不要把它当救命稻草，应用的根基(数据库设计，算法，高效的操作语句，恰当API的选择等)才是最重要的。