在处理大数据量时，会有大量的数据缓冲保存在 Session 的一级缓存中，这缓存大太时会严重显示性能，所以在使用 Hibernate 处理大数据量的，可以使用 session.clear() 或者 session. Evict(Object) 在处理过程中，清除全部的缓存或者清除某个对象。
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 中的集合没有被使用时，就可减少互数据库的交互从而减少处理时间。
6) 对于大数据量新增、修改、删除操作或者是对大数据量的查询，与数据库的交互次数是决定处理时间的最重要因素，减少交互的次数是提升效率的最好途径，所以在开发过程中，请将 show_sql 设置为 true ，深入了解 Hibernate 的处理过程，尝试不同的方式，可以使得效率提升。
7) Hibernate 是以 JDBC 为基础，但是 Hibernate 是对 JDBC 的优化，其中使用 Hibernate 的缓冲机制会使性能提升，如使用二级缓存以及查询缓存，若命中率较高明，性能会是到大幅提升。
8) Hibernate 可以通过设置 hibernate.jdbc.fetch_size ， hibernate.jdbc.batch_size 等属性，对 Hibernate 进行优化。
9) 不过值得注意的是，一些数据库提供的主键生成机制在效率上未必最佳，大量并发 insert 数据时可能会引起表之间的互锁。数据库提供的主键生成机制，往往是通过在一个内部表中保存当前主键状态（如对于自增型主键而言，此内部表中就维护着当前的最大值和递增量），之后每次插入数据会读取这个最大值，然后加上递增量作为新记录的主键，之后再把这个新的最大值更新回内部表中，这样，一次 Insert 操作可能导致数据库内部多次表读写操作，同时伴随的还有数据的加锁解锁操作，这对性能产生了较大影响。
因此，对于并发 Insert 要求较高的系统，推荐采用 uuid.hex 作为主键生成机制。
10) Dynamic Update 如果选定，则生成 Update SQL 时不包含未发生变动的字段属性，这样可以在一定程度上提升 SQL 执行效能 . Dynamic Insert 如果选定，则生成 Insert SQL 时不包含未发生变动的字段属性，这样可以在一定程度上提升 SQL 执行效能
11) 在编写代码的时候请，对将 POJO 的 getter/setter 方法设定为 public ，如果设定为 private ， Hibernate 将无法对属性的存取进行优化，只能转而采用传统的反射机制进行操作，这将导致大量的性能开销（特别是在 1.4 之前的 Sun JDK 版本以及 IBM JDK 中，反射所带来的系统开销相当可观）。
12) 在 one-to-many 关系中，将 many 一方设为主动方（ inverse=false ）将有助性能的改善
13) 由于多对多关联的性能不佳（由于引入了中间表，一次读取操作需要反复数次查询），因此在设计中应该避免大量使用 .
14) Hibernate 支持两种锁机制：即通常所说的“悲观锁（ Pessimistic Locking ）”和“乐观锁（ Optimistic Locking ）”。 悲观锁带来 数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题.乐观锁机制避免了长事务中的数据库加锁开销,大大提升了大并发量下的系统整体性能表现。
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 中的集合没有被使用时，就可减少互数据库的交互从而减少处理时间。
6) 对于大数据量新增、修改、删除操作或者是对大数据量的查询，与数据库的交互次数是决定处理时间的最重要因素，减少交互的次数是提升效率的最好途径，所以在开发过程中，请将 show_sql 设置为 true ，深入了解 Hibernate 的处理过程，尝试不同的方式，可以使得效率提升。
7) Hibernate 是以 JDBC 为基础，但是 Hibernate 是对 JDBC 的优化，其中使用 Hibernate 的缓冲机制会使性能提升，如使用二级缓存以及查询缓存，若命中率较高明，性能会是到大幅提升。
8) Hibernate 可以通过设置 hibernate.jdbc.fetch_size ， hibernate.jdbc.batch_size 等属性，对 Hibernate 进行优化。
9) 不过值得注意的是，一些数据库提供的主键生成机制在效率上未必最佳，大量并发 insert 数据时可能会引起表之间的互锁。数据库提供的主键生成机制，往往是通过在一个内部表中保存当前主键状态（如对于自增型主键而言，此内部表中就维护着当前的最大值和递增量），之后每次插入数据会读取这个最大值，然后加上递增量作为新记录的主键，之后再把这个新的最大值更新回内部表中，这样，一次 Insert 操作可能导致数据库内部多次表读写操作，同时伴随的还有数据的加锁解锁操作，这对性能产生了较大影响。
因此，对于并发 Insert 要求较高的系统，推荐采用 uuid.hex 作为主键生成机制。
10) Dynamic Update 如果选定，则生成 Update SQL 时不包含未发生变动的字段属性，这样可以在一定程度上提升 SQL 执行效能 . Dynamic Insert 如果选定，则生成 Insert SQL 时不包含未发生变动的字段属性，这样可以在一定程度上提升 SQL 执行效能
11) 在编写代码的时候请，对将 POJO 的 getter/setter 方法设定为 public ，如果设定为 private ， Hibernate 将无法对属性的存取进行优化，只能转而采用传统的反射机制进行操作，这将导致大量的性能开销（特别是在 1.4 之前的 Sun JDK 版本以及 IBM JDK 中，反射所带来的系统开销相当可观）。
12) 在 one-to-many 关系中，将 many 一方设为主动方（ inverse=false ）将有助性能的改善
13) 由于多对多关联的性能不佳（由于引入了中间表，一次读取操作需要反复数次查询），因此在设计中应该避免大量使用 .
14) Hibernate 支持两种锁机制：即通常所说的“悲观锁（ Pessimistic Locking ）”和“乐观锁（ Optimistic Locking ）”。 悲观锁带来 数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题.乐观锁机制避免了长事务中的数据库加锁开销,大大提升了大并发量下的系统整体性能表现。
扫一扫
127
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
