浅谈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))

总结

以上就是本文关于浅谈hibernate n+1问题的全部内容，希望对大家有所帮助。感兴趣的朋友可以继续参阅本站其他相关专题，如有不足之处，欢迎留言指出。感谢朋友们对本站的支持！