淺談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問題的全部內容，希望對大家有所幫助。感興趣的朋友可以繼續參閱本站其他相關專題，如有不足之處，歡迎留言指出。感謝朋友們對本站的支持！