大體上，對HIBERNATE性能調(diào)優(yōu)的主要斟酌點以下:
? 數(shù)據(jù)庫設(shè)計調(diào)劑
? HQL優(yōu)化
? API的正確使用(如根據(jù)不同的業(yè)務(wù)類型選用不同的集合及查詢API)
? 主配置參數(shù)(日志，查詢緩存，fetch_size, batch_size等)
? 映照文件優(yōu)化(ID生成策略，2級緩存，延遲加載，關(guān)聯(lián)優(yōu)化)
? 1級緩存的管理
? 針對2級緩存，還有許多獨有的策略
? 事務(wù)控制策略。

1、 數(shù)據(jù)庫設(shè)計

a) 下降關(guān)聯(lián)的復(fù)雜性
b) 盡可能不使用聯(lián)合主鍵
c) ID的生成機(jī)制，不同的數(shù)據(jù)庫所提供的機(jī)制其實不完全1樣
d) 適當(dāng)?shù)娜哂鄶?shù)據(jù)，不過分尋求高范式

2、 HQL優(yōu)化

HQL如果拋開它同HIBERNATE本身1些緩存機(jī)制的關(guān)聯(lián)，HQL的優(yōu)化技能同普通的SQL優(yōu)化技能1樣，可以很容易在網(wǎng)上找到1些經(jīng)驗之談。

3、 主配置

a) 查詢緩存，同下面講的緩存不太1樣，它是針對HQL語句的緩存，即完全1樣的語句再次履行時可以利用緩存數(shù)據(jù)。但是，查詢緩存在1個交易系統(tǒng)(數(shù)據(jù)變更頻繁，查詢條件相同的機(jī)率其實不大)中可能會起反作用:它會白白耗費大量的系統(tǒng)資源但卻難以派上用處。
b) fetch_size，同JDBC的相干參數(shù)作用類似，參數(shù)其實不是越大越好，而應(yīng)根據(jù)業(yè)務(wù)特點去設(shè)置
c) batch_size同上。
d) 生產(chǎn)系統(tǒng)中，切紀(jì)要關(guān)掉SQL語句打印。

4、 緩存

a) 數(shù)據(jù)庫級緩存:這級緩存是最高效和安全的，但不同的數(shù)據(jù)庫可管理的層次其實不1樣，比如，在ORACLE中，可以在建表時指定將全部表置于緩存當(dāng)中。

b) SESSION緩存:在1個HIBERNATE SESSION有效，這級緩存的可干預(yù)性不強(qiáng)，大多于HIBERNATE自動管理，但它提供清除緩存的方法，這在大批量增加/更新操作是有效的。比如，同時增加10萬條記錄，按常規(guī)方式進(jìn)行，極可能會發(fā)現(xiàn)OutofMemeroy的異常，這時候可能需要手動清除這1級緩存:Session.evict和Session.clear

c) 利用緩存:在1個SESSIONFACTORY中有效，因此也是優(yōu)化的重中之重，因此，各類策略也斟酌的較多，在將數(shù)據(jù)放入這1級緩存之前，需要斟酌1些條件條件:

i. 數(shù)據(jù)不會被第3方修改(比如，是不是有另外一個利用也在修改這些數(shù)據(jù)?)
ii. 數(shù)據(jù)不會太大
iii. 數(shù)據(jù)不會頻繁更新(否則使用CACHE可能適得其反)
iv. 數(shù)據(jù)會被頻繁查詢
v. 數(shù)據(jù)不是關(guān)鍵數(shù)據(jù)(如觸及錢，安全等方面的問題)。

緩存有幾種情勢，可以在映照文件中配置:read-only(只讀，適用于很少變更的靜態(tài)數(shù)據(jù)/歷史數(shù)據(jù))，nonstrict-read-write，read-write(比較普遍的情勢，效力1般)，transactional(JTA中，且支持的緩存產(chǎn)品較少)

d) 散布式緩存:同c)的配置1樣，只是緩存產(chǎn)品的選用不同，在目前的HIBERNATE中可供選擇的不多，oscache, jboss cache，目前的大多數(shù)項目，對它們的用于集群的使用(特別是關(guān)鍵交易系統(tǒng))都持守舊態(tài)度。在集群環(huán)境中，只利用數(shù)據(jù)庫級的緩存是最安全的。

5、 延遲加載
a) 實體延遲加載:通過使用動態(tài)代理實現(xiàn)

b) 集合延遲加載:通過實現(xiàn)自有的SET/LIST，HIBERNATE提供了這方面的支持

c) 屬性延遲加載:

6、 方法選用

a) 完成一樣1件事，HIBERNATE提供了可供選擇的1些方式，但具體使用甚么方式，可能用性能/代碼都會有影響。顯示，1次返回10萬條記錄(List/Set/Bag/Map等)進(jìn)行處理，極可能致使內(nèi)存不夠的問題，而如果用基于游標(biāo)(ScrollableResults)或Iterator的結(jié)果集，則不存在這樣的問題。

b) Session的load/get方法，前者會使用2級緩存，而后者則不使用。

c) Query和list/iterator，如果去仔細(xì)研究1下它們，你可能會發(fā)現(xiàn)很多成心思的情況，2者主要區(qū)分(如果使用了Spring，在HibernateTemplate中對應(yīng)find,iterator方法):

i. list只能利用查詢緩存(但在交易系統(tǒng)中查詢緩存作用不大)，沒法利用2級緩存中的單個實體，但list查出的對象會寫入2級緩存，但它1般只生成較少的履行SQL語句，很多情況就是1條(無關(guān)聯(lián))。

ii. iterator則可以利用2級緩存，對1條查詢語句，它會先從數(shù)據(jù)庫中找出所有符合條件的記錄的ID，再通過ID去緩存找，對緩存中沒有的記錄，再構(gòu)造語句從數(shù)據(jù)庫中查出，因此很容易知道，如果緩存中沒有任何符合條件的記錄，使用iterator會產(chǎn)生N+1條SQL語句(N為符合條件的記錄數(shù))

iii. 通過iterator，配合緩存管理API，在海量數(shù)據(jù)查詢中可以很好的解決內(nèi)存問題，如:
while(it.hasNext()){
YouObject object = (YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
}
如果用list方法，極可能就出OutofMemory毛病了。

iv. 通過上面的說明，我想你應(yīng)當(dāng)知道如何去使用這兩個方法了。

7、 集合的選用
在HIBERNATE 3.1文檔的“19.5. Understanding Collection performance”中有詳細(xì)的說明。

8、 事務(wù)控制

事務(wù)方面對性能有影響的主要包括:事務(wù)方式的選用，事務(wù)隔離級別和鎖的選用

a) 事務(wù)方式選用:如果不觸及多個事務(wù)管理器事務(wù)的話，不需要使用JTA，只有JDBC的事務(wù)控制就能夠。

b) 事務(wù)隔離級別:參見標(biāo)準(zhǔn)的SQL事務(wù)隔離級別

c) 鎖的選用:悲觀鎖(1般由具體的事務(wù)管理器實現(xiàn))，對長事務(wù)效力低，但安全。樂觀鎖(1般在利用級別實現(xiàn))，如在HIBERNATE中可以定義VERSION字段，明顯，如果有多個利用操作數(shù)據(jù)，且這些利用不是用同1種樂觀鎖機(jī)制，則樂觀鎖會失效。因此，針對不同的數(shù)據(jù)應(yīng)有不同的策略，同前面許多情況1樣，很多時候我們是在效力與安全/準(zhǔn)確性上找1個平衡點，不管如何，優(yōu)化都不是1個純技術(shù)的問題，你應(yīng)當(dāng)對你的利用和業(yè)務(wù)特點有足夠的了解。

9、 批量操作

即便是使用JDBC，在進(jìn)行大批數(shù)據(jù)更新時，BATCH與不使用BATCH有效力上也有很大的差別。我們可以通過設(shè)置batch_size來讓其支持批量操作。
舉個例子，要批量刪除某表中的對象，如“delete Account”，打出來的語句，會發(fā)現(xiàn)HIBERNATE找出了所有ACCOUNT的ID，再進(jìn)行刪除，這主要是為了保護(hù)2級緩存，這樣效力肯定高不了，在后續(xù)的版本中增加了bulk delete/update，但這也沒法解決緩存的保護(hù)問題。也就是說，由于有了2級緩存的保護(hù)問題，HIBERNATE的批量操作效力其實不盡如人意!

從前面許多要點可以看出，很多時候我們是在效力與安全/準(zhǔn)確性上找1個平衡點，不管如何，優(yōu)化都不是1個純技術(shù)的問題，你應(yīng)當(dāng)對你的利用和業(yè)務(wù)特點有足夠的了解，1般的，優(yōu)化方案應(yīng)在架構(gòu)設(shè)計期就基本肯定，否則可能致使沒必要的返工，導(dǎo)致項目延期，而作為架構(gòu)師和項目經(jīng)理，還要面對開發(fā)人員可能的抱怨，必竟，我們對用戶需求更改的控制力不大，但技術(shù)/架構(gòu)風(fēng)險是應(yīng)當(dāng)在早期意想到并制定好相干的對策。

還有1點要注意，利用層的緩存只是錦上添花，永久不要把它當(dāng)救命稻草，利用的根基(數(shù)據(jù)庫設(shè)計，算法，高效的操作語句，恰當(dāng)API的選擇等)才是最重要的。