Hibernate - 分页引发的问题

   

前几天查看后台的日志时,发现常出现Hibernate的警告信息:

WARN (org.hibernate.hql.ast.QueryTranslatorImpl:328) - firstResult/maxResults specified with collection fetch; applying in memory!

在中文Google上搜了搜,没有找到什么有用的信息,之后在英文的Google上搜了一下,出了很多介绍这方面的文章,写的最好的,我觉得是这篇文章,有测试用例来说明一切:

http://java.dzone.com/articles/hibernate-tuning-queries-using?page=0,0

我大概总结一下:在查询一对多关系数据,后面会用到“多”的数据。数据量比较大的时候(从数据库取500条记录以上),用fetch join比较好,Hibernate官方的文档也说了,它会只执行1SQL语句。但是如果用分页查询时,比如一次才取50条数据时,不用fetch join要快,因为如果用了fetch join后,hibernate并不能在数据库进行分页,会把所有数据库到内存中,然后分页,当然性能 会差的很远(所以会报一个前面我写的警告信息)。这时用延时加载比如快,这时还可以更加优化,通过指定batch-size的大小,来批量从数据中读。

通过自己的测试,光是Hibernate发出的SQL语句就少了很多。之前我用Fetch join用分布时有200多条Sql语句产生,不用fetch join时只有23条了,再加了batch-size优化后只有16sql了。所以要对不同的情况,进行不同的优化,才能让性能最佳!

 

注: 转自网友:http://yh1022.iteye.com/blog/295750

=============================================================

  在使用Hibernate进行分页的过程中,如果你收到如下警告,那么这里就是一个潜在的性能问题点:

WARNING: firstResult/maxResults specified with collection fetch; applying in memory!

  出现这个警告的直接后果是:无论你想要看第几页的数据,从Hibernate打印出的SQL来看它总是查询了所有满足条件的结果。这是为什么呢?来看看这句警告所在的代码,它位于org.hibernate.hql.ast.QueryTranslatorImpl中,部分摘录如下:

[java] view plaincopy

1.   QueryNode query = ( QueryNode ) sqlAst;  

2.     

3.   boolean hasLimit = queryParameters.getRowSelection() != null && queryParameters.getRowSelection().definesLimits();  

4.     

5.   boolean needsDistincting = ( query.getSelectClause().isDistinct() || hasLimit ) && containsCollectionFetches();  

6.     

7.     

8.     

9.   QueryParameters queryParametersToUse;  

10.    

11.  if ( hasLimit && containsCollectionFetches() ) {  

12.    

13.       log.warn( "firstResult/maxResults specified with collection fetch; applying in memory!" );  

14.    

15.      RowSelection selection = new RowSelection();  

16.    

17.      selection.setFetchSize( queryParameters.getRowSelection().getFetchSize() );  

18.    

19.      selection.setTimeout( queryParameters.getRowSelection().getTimeout() );  

20.    

21.      queryParametersToUse = queryParameters.createCopyUsing( selection );  

22.    

23.  }  

24.    

25.  else {  

26.    

27.      queryParametersToUse = queryParameters;  

28.    

29.  }  

30.    

31.    

32.    

33.  List results = queryLoader.list( session, queryParametersToUse );  

  关键在于if ( hasLimit && containsCollectionFetches() 这句判断,如果满足了这个条件,RowSelection将会被重新生成,原本分页需要的firstRow和maxRows属性将会丢失,后面的数据库分页自然也无法进行。Hibernate这么做的原因从代码上也很容易理解,如果查询需要限制条数(limit/offset)并且需要fetch结合对象,则重新生成RowSelection,进一步解释,就是当一个实体(A)和另一个实体(B)是One-To-Many关系的时候,一个需要fetch的典型查询语句是“select distinct a from A a left join fetch a.b”,由于1个A可能对应多个B,这个时候数据库查询的结果条数和需要生成的A对象的条数可能不一致,所以无法利用数据库层的分页来实现,因为你真正想分页的是A而不是A left join B。出现这个警告就是提醒你这个查询实际上是查询了所有满足条件的数据,Hibernate是在内存中对其进行了假分页的处理。

  这样,对于查询结果比较多的情况无疑是一个性能上的潜在威胁。碰到这样的情况,将Many的查询进行分开也是一种解决办法。

注: 转自网友 http://blog.csdn.net/tdl982324/article/details/2607899

 





posted @ 2012-12-06 21:29  戴眼镜的码农  阅读(878)  评论(0编辑  收藏  举报