在Session的緩存中存放的是相互關(guān)聯(lián)的對(duì)象圖。默認(rèn)情況下，當(dāng)Hibernate從數(shù)據(jù)庫(kù)中加載Customer對(duì)象時(shí)，會(huì)同時(shí)加載所有關(guān)聯(lián)的 Order對(duì)象。以Customer和Order類為例，假定ORDERS表的CUSTOMER_ID外鍵允許為null

以下Session的find()方法用于到數(shù)據(jù)庫(kù)中檢索所有的Customer對(duì)象： 

List customerLists=session.find("from Customer as c"); 

運(yùn)行以上find()方法時(shí)，Hibernate將先查詢CUSTOMERS表中所有的記錄，然后根據(jù)每條記錄的ID，到ORDERS表中查詢有參照關(guān)系的記錄，Hibernate將依次執(zhí)行以下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個(gè)Customer對(duì)象和5個(gè)Order對(duì)象，在內(nèi)存中形成了一幅關(guān)聯(lián)的對(duì)象圖.


Hibernate在檢索與Customer關(guān)聯(lián)的Order對(duì)象時(shí)，使用了默認(rèn)的立即檢索策略。這種檢索策略存在兩大不足： 

（1） select語句的數(shù)目太多，需要頻繁的訪問數(shù)據(jù)庫(kù)，會(huì)影響檢索性能。如果需要查詢n個(gè)Customer對(duì)象，那么必須執(zhí)行n+1次select查詢語 句。這就是經(jīng)典的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）在應(yīng)用邏輯只需要訪問Customer對(duì)象，而不需要訪問Order對(duì)象的場(chǎng)合，加載Order對(duì)象完全是多余的操作，這些多余的Order對(duì)象白白浪費(fèi)了許多內(nèi)存空間。 
為了解決以上問題，Hibernate提供了其他兩種檢索策略：延遲檢索策略和迫切左外連接檢索策略。延遲檢索策略能避免多余加載應(yīng)用程序不需要訪問的關(guān)聯(lián)對(duì)象，迫切左外連接檢索策略則充分利用了SQL的外連接查詢功能，能夠減少select語句的數(shù)目。

對(duì)數(shù)據(jù)庫(kù)訪問還是必須考慮性能問題的， 在設(shè)定了1 對(duì)多這種關(guān)系之后， 查詢就會(huì)出現(xiàn)傳說中的n +1 問題。 
1 ）1 對(duì)多，在1 方，查找得到了n 個(gè)對(duì)象， 那么又需要將n 個(gè)對(duì)象關(guān)聯(lián)的集合取出，于是本來的一條sql查詢變成了n +1 條 
2）多對(duì)1 ，在多方，查詢得到了m個(gè)對(duì)象，那么也會(huì)將m個(gè)對(duì)象對(duì)應(yīng)的1 方的對(duì)象取出， 也變成了m+1

怎么解決n +1 問題？ 
1 ）lazy=true， hibernate3開始已經(jīng)默認(rèn)是lazy=true了；lazy=true時(shí)不會(huì)立刻查詢關(guān)聯(lián)對(duì)象，只有當(dāng)需要關(guān)聯(lián)對(duì)象（訪問其屬性，非id字段）時(shí)才會(huì)發(fā)生查詢動(dòng)作。 

2）二級(jí)緩存， 在對(duì)象更新，刪除，添加相對(duì)于查詢要少得多時(shí)， 二級(jí)緩存的應(yīng)用將不怕n +1 問題，因?yàn)榧词沟谝淮尾樵兒苈?，之后直接緩存命中也是很快的?nbsp;
不同解決方法，不同的思路，第二條卻剛好又利用了n +1 。

3) 當(dāng)然你也可以設(shè)定fetch=join(annotation : @ManyToOne() @Fetch(FetchMode.JOIN))