本文依照HIBERNATE幫助文檔，一些網(wǎng)絡(luò)書籍及項目經(jīng)驗整理而成，只提供要點和思路，具體做法可以留言探討，或是找一些更具體更有針對性的資料。

　　初用HIBERNATE的人也許都碰到過性能問題，實現(xiàn)同一功能，用HIBERNATE與用JDBC性能相差十幾倍很正常，假如不及早調(diào)整，很可能影響整個項目的進度。

　　大體上，對于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生成策略，二級緩存，延遲加載，關(guān)聯(lián)優(yōu)化)

　　Ø 一級緩存的治理

　　Ø 針對二級緩存，還有許多特有的策略

　　Ø 事務(wù)控制策略。

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

　　a) 降低關(guān)聯(lián)的復(fù)雜性

　　b) 盡量不使用聯(lián)合主鍵

　　c) ID的生成機制，不同的數(shù)據(jù)庫所提供的機制并不完全一樣

　　d) 適當?shù)娜哂鄶?shù)據(jù)，不過分追求高范式

　　2、 HQL優(yōu)化

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

　　3、 主配置

　　a) 查詢緩存，同下面講的緩存不太一樣，它是針對HQL語句的緩存，即完全一樣的語句再次執(zhí)行時可以利用緩存數(shù)據(jù)。但是，查詢緩存在一個交易系統(tǒng)(數(shù)據(jù)變更頻繁，查詢條件相同的機率并不大)中可能會起反作用:它會白白耗費大量的系統(tǒng)資源但卻難以派上用場。

　　b) fetch_size，同JDBC的相關(guān)參數(shù)作用類似，參數(shù)并不是越大越好，而應(yīng)根據(jù)業(yè)務(wù)特征去設(shè)置

　　c) batch_size同上。

　　d) 生產(chǎn)系統(tǒng)中，切記要關(guān)掉SQL語句打印。

　　4、 緩存

　　a) 數(shù)據(jù)庫級緩存:這級緩存是最高效和安全的，但不同的數(shù)據(jù)庫可治理的層次并不一樣，比如，在Oracle中，可以在建表時指定將整個表置于緩存當中。

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

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

　　i. 數(shù)據(jù)不會被第三方修改(比如，是否有另一個應(yīng)用也在修改這些數(shù)據(jù)?)

　　ii. 數(shù)據(jù)不會太大

　　iii. 數(shù)據(jù)不會頻繁更新(否則使用CACHE可能適得其反)

　　iv. 數(shù)據(jù)會被頻繁查詢

　　v. 數(shù)據(jù)不是要害數(shù)據(jù)(如涉及錢，安全等方面的問題)。

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

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

　　5、 延遲加載

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

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

　　c) 屬性延遲加載:

　　6、 方法選用

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

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

　　c) Query和list/iterator，假如去仔細研究一下它們，你可能會發(fā)現(xiàn)很多有意思的情況，二者主要區(qū)別(假如使用了SPRing，在HibernateTemplate中對應(yīng)find,iterator方法):

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

　　ii. iterator則可以利用二級緩存，對于一條查詢語句，它會先從數(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();