两三周之前遇到的一个问题,终于在今天解决,感觉心情舒畅啊!
hibernate查询数据库时,不知道什么原因变得非常的慢,但是同样的代码在另外的服务器上却一点问题也不慢。一直以为是内存的原因,因为生产用的服务器的内存不记得是32G还是64G的了,自己的电脑是2G而且还是远程操作,再加上要做其他任务开发,所以一直没有踏实地去解决这个问题。过去的两周里都是在刷页面,打开一个主要页面要等20分钟左右,有时候要多登录不同的用户进行测试则需要等上1个小时,如果测试不通过,又得再等一个小时,这开发效率极慢,所以只好加班加点地把开发任务做完。
近两天,终于做完开发任务,便开始主攻这个hibernate查询缓慢的问题。
关于这个问题,咨询过很多同事,以及IT行业的同学朋友
主要朝下面几个方向去思考解决:
1,SQL调优,建索引
2,代码是否设计合理
3,查看LOG日志文件,hibernate查询语句的输出
4,N+1问题
因为半路出家进入程序猿行业,所以前面的1、2未作为第一选择,3也查看了发现有许多的select语句,后确定是N+1问题。
如果当SQL数据库中select语句数目过多,就会影响数据库的性能,如果需要查询n个Customer对象,那么必须执行n+1次select查询语句,下文就将为您讲解这个n+1次select查询问题。
在Session的缓存中存放的是相互关联的对象图。默认情况下,当Hibernate从数据库中加载Customer对象时,会同时加载所有关联的Order对象。以Customer和Order类为例,假定ORDERS表的CUSTOMER_ID外键允许为null,图1列出了CUSTOMERS表和ORDERS表中的记录。
以下Session的find()方法用于到数据库中检索所有的Customer对象:
List customerLists=session.find("from Customer as c");
运行以上find()方法时,Hibernate将先查询CUSTOMERS表中所有的记录,然后根据每条记录的ID,到ORDERS表中查询有参照关系的记录,Hibernate将依次执行以下select语句:
select * from CUSTOMERS;
select * from ORDERS where CUSTOMER_ID=1;
select * from ORDERS where CUSTOMER_ID=2;
select * from ORDERS where CUSTOMER_ID=3;
select * from ORDERS where CUSTOMER_ID=4;
Hibernate在检索与Customer关联的Order对象时,使用了默认的立即检索策略。这种检索策略存在两大不足:
(1) select语句的数目太多,需要频繁的访问数据库,会影响检索性能。如果需要查询n个Customer对象,那么必须执行n+1次select查询语句。这就是经典的n+1次select查询问题。这种检索策略没有利用SQL的连接查询功能,例如以上5条select语句完全可以通过以下1条select语句来完成:
select * from CUSTOMERS left outer join ORDERS
on CUSTOMERS.ID=ORDERS.CUSTOMER_ID
以上select语句使用了SQL的左外连接查询功能,能够在一条select语句中查询出CUSTOMERS表的所有记录,以及匹配的ORDERS表的记录。
(2)在应用逻辑只需要访问Customer对象,而不需要访问Order对象的场合,加载Order对象完全是多余的操作,这些多余的Order对象白白浪费了许多内存空间。
为了解决以上问题,Hibernate提供了其他两种检索策略:延迟检索策略和迫切左外连接检索策略。延迟检索策略能避免多余加载应用程序不需要访问的关联对象,迫切左外连接检索策略则充分利用了SQL的外连接查询功能,能够减少select语句的数目。
为了解决以上问题,Hibernate提供了两种检索策略:延迟检索策略和迫切左外连接检索策略
1、延迟检索策略能避免多余加载应用程序不需要访问的关联对象,
hibernate3开始已经默认是lazy=true了;lazy=true时不会立刻查询关联对象,只有当需要关联对象(访问其属性)时才会发生查询动作。
2、迫切左外连接检索策略则充分利用了SQL的外连接查询功能,能够减少select语句的数目。
可以在映射文件中定义连接抓取方式。
<set name=”orders” fetch=”join”>
<key column=”customer_id”>
<one-to-many class="com.hibernate.mappings.Order"/>
</set>
或者使用HQL的LEFT OUTER JOIN.
或者在条件查询中使用setFetchMode(FetchMode.JOIN)
Customer ctm = (Customer)session.createCriteria(Customer.class)
.setFetchMode(“Order”.JOIN)
.add(Restrictions.idEq(customer_id));
因为关联到的表比较多近20张,一开始胡乱地给所有的set都添加 fetch="join" 查看相关的抓取策略 又修改了相关表的lazy属性,导致出现许多问题,如
http://1259988502.iteye.com/blog/1893450
相关推荐
* N+1 与 1+M:针对一端,如果查询有 m 个对象,这时会先发送 1 条 sql 语句查出 m 个对象,然后再发送 m 条 sql 语句查关联对象 七、事务控制 * 事务方面对性能有影响的主要包括:事务方式的选用、事务隔离级别...
27、用 JDBC 查询学生成绩单, 把主要代码写出来(考试概率极大). 112 28、这段代码有什么不足之处? 112 29、说出数据连接池的工作机制是什么? 113 30、为什么要用 ORM? 和 JDBC 有何不一样? 113 六. XML部分 113 1...
27、用 JDBC 查询学生成绩单, 把主要代码写出来(考试概率极大). 112 28、这段代码有什么不足之处? 112 29、说出数据连接池的工作机制是什么? 113 30、为什么要用 ORM? 和 JDBC 有何不一样? 113 六. XML部分 113 1...
27、用 JDBC 查询学生成绩单, 把主要代码写出来(考试概率极大). 112 28、这段代码有什么不足之处? 112 29、说出数据连接池的工作机制是什么? 113 30、为什么要用 ORM? 和 JDBC 有何不一样? 113 六. XML部分 113 1...
27、用 JDBC 查询学生成绩单, 把主要代码写出来(考试概率极大). 122 28、这段代码有什么不足之处? 123 29、说出数据连接池的工作机制是什么? 123 30、为什么要用 ORM? 和 JDBC 有何不一样? 123 六. XML部分 124 1...
27、用 JDBC 查询学生成绩单, 把主要代码写出来(考试概率极大). 112 28、这段代码有什么不足之处? 112 29、说出数据连接池的工作机制是什么? 113 30、为什么要用 ORM? 和 JDBC 有何不一样? 113 六. XML部分 113 1...
27、用 JDBC 查询学生成绩单, 把主要代码写出来(考试概率极大). 112 28、这段代码有什么不足之处? 112 29、说出数据连接池的工作机制是什么? 113 30、为什么要用 ORM? 和 JDBC 有何不一样? 113 六. XML部分 ...
27、用 JDBC 查询学生成绩单, 把主要代码写出来(考试概率极大). 112 28、这段代码有什么不足之处? 112 29、说出数据连接池的工作机制是什么? 113 30、为什么要用 ORM? 和 JDBC 有何不一样? 113 六. XML部分 113 1...
`TreeMap`基于红黑树实现,保持键的自然排序或自定义排序,提供O(log n)的时间复杂度;`LinkedHashMap`保持元素的插入顺序,提供较快的遍历速度。 - **ArrayList**和**Vector**:`ArrayList`和`Vector`都实现了`...
经常的进行知识难点的查询,如果一个问题牵扯的面比较广,就干脆到网上搜索一些相关的专题,比如“java 乱码 mysql” “oracle 创建用户”等等,如果有必要,不要犯懒,勤动手写一些小小的测试程序,来弄明白知识点...