hibernate N+1问题 Hql的fetch

Hql的fetch

在我们查询Parent对象的时候，默认只有Parent的内容，并不包含childs的信息，如果在Parent.hbm.xml里设置lazy="false"的话才同时取出关联的所有childs内容.
     问题是我既想要hibernate默认的性能又想要临时的灵活性该怎么办？  这就是fetch的功能。我们可以把fetch与lazy="true"的关系类比为事务当中的编程式事务与声明式事务,不太准确，但是大概是这个意思。
总值，fetch就是在代码这一层给你一个主动抓取得机会.

[java]  view plain copy

1. Parent parent = (Parent)hibernateTemplate.execute(new HibernateCallback() {  
2. public Object doInHibernate(Session session) throws HibernateException, SQLException {  
3.                 Query q = session.createQuery(  
4. "from Parent as parent "+  
5. " left outer join fetch parent.childs " +  
6. " where parent.id = :id"  
7.                 );  
8.                 q.setParameter("id",new Long(15));  
9. return (Parent)q.uniqueResult();  
10.             }  
11.         });  
12.         Assert.assertTrue(parent.getChilds().size() > 0);   

    你可以在lazy="true"的情况下把fetch去掉，就会报异常. 当然，如果lazy="false"就不需要fetch了。

 

 

转自http://blog.csdn.net/Yokubee/archive/2010/08/09/5799138.aspx

 

    fetch设置为lazy，查询Parent对象的时候，默认只有Parent的内容，并不包含child的信息，这样可以避免n+1问题。

    但又想查询parent时把children得到，就可以用fetch。

    fetch主动将child得到并set到children列表中。

    HQL语句：from Parent p left join fetch p.children

 

转自http://hi.baidu.com/sunyu830317/blog/item/58af68015375d30d7bec2cf0.html

 

   fetch关键字强制Hibernate进行集合填充操作

   如:from TUser user inner join  fetch user.addresses

   这里的"fetch"关键字表明TAddress对象读出以后立即填充到对应的TUser对象中。

Hibernate n+1问题

在Session的缓存中存放的是相互关联的对象图。默认情况下，当Hibernate从数据库中加载Customer对象时，会同时加载所有关联的 Order对象。以Customer和Order类为例，假定ORDERS表的CUSTOMER_ID外键允许为null

以下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; 

通过以上5条select语句，Hibernate最后加载了4个Customer对象和5个Order对象，在内存中形成了一幅关联的对象图.


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语句的数目。

对数据库访问还是必须考虑性能问题的， 在设定了1 对多这种关系之后， 查询就会出现传说中的n +1 问题。 
1 ）1 对多，在1 方，查找得到了n 个对象， 那么又需要将n 个对象关联的集合取出，于是本来的一条sql查询变成了n +1 条 
2）多对1 ，在多方，查询得到了m个对象，那么也会将m个对象对应的1 方的对象取出， 也变成了m+1

怎么解决n +1 问题？ 
1 ）lazy=true， hibernate3开始已经默认是lazy=true了；lazy=true时不会立刻查询关联对象，只有当需要关联对象（访问其属性，非id字段）时才会发生查询动作。 

2）二级缓存， 在对象更新，删除，添加相对于查询要少得多时， 二级缓存的应用将不怕n +1 问题，因为即使第一次查询很慢，之后直接缓存命中也是很快的。 
不同解决方法，不同的思路，第二条却刚好又利用了n +1 。

3) 当然你也可以设定fetch=join(annotation : @ManyToOne() @Fetch(FetchMode.JOIN))