本文依照HIBERNATE幫助文檔，一些網絡書籍及項目經驗整理而成，只提供要點和思路，具體做法可以留言探討，或是找一些更詳細更有針對性的資料。
初用HIBERNATE的人也許都遇到過性能問題，實現(xiàn)同一功能，用HIBERNATE與用JDBC性能相差十幾倍很正常，如果不及早調整，很可能影響整個項目的進度。
大體上，對于HIBERNATE性能調優(yōu)的主要考慮點如下：
Ø 數(shù)據(jù)庫設計調整
Ø HQL優(yōu)化
Ø API的正確使用（如根據(jù)不同的業(yè)務類型選用不同的集合及查詢API）
Ø 主配置參數(shù)（日志，查詢緩存，fetch_size, batch_size等）
Ø 映射文件優(yōu)化（ID生成策略，二級緩存，延遲加載，關聯(lián)優(yōu)化）
Ø 一級緩存的管理
Ø 針對二級緩存，還有許多特有的策略
Ø 事務控制策略。
1、 數(shù)據(jù)庫設計
a) 降低關聯(lián)的復雜性
b) 盡量不使用聯(lián)合主鍵
c) ID的生成機制，不同的數(shù)據(jù)庫所提供的機制并不完全一樣
d) 適當?shù)娜哂鄶?shù)據(jù)，不過分追求高范式
2、HQL優(yōu)化
HQL如果拋開它同HIBERNATE本身一些緩存機制的關聯(lián)，HQL的優(yōu)化技巧同普通的SQL優(yōu)化技巧一樣，可以很容易在網上找到一些經驗之談。
3、 主配置
a) 查詢緩存，同下面講的緩存不太一樣，它是針對HQL語句的緩存，即完全一樣的語句再次執(zhí)行時可以利用緩存數(shù)據(jù)。但是，查詢緩存在一個交易系統(tǒng)（數(shù)據(jù)變更頻繁，查詢條件相同的機率并不大）中可能會起反作用：它會白白耗費大量的系統(tǒng)資源但卻難以派上用場。
b) fetch_size，同JDBC的相關參數(shù)作用類似，參數(shù)并不是越大越好，而應根據(jù)業(yè)務特征去設置
c) batch_size同上。
d) 生產系統(tǒng)中，切記要關掉SQL語句打印。
4、 緩存
a) 數(shù)據(jù)庫級緩存：這級緩存是最高效和安全的，但不同的數(shù)據(jù)庫可管理的層次并不一樣，比如，在ORACLE中，可以在建表時指定將整個表置于緩存當中。
b) SESSION緩存：在一個HIBERNATE SESSION有效，這級緩存的可干預性不強，大多于HIBERNATE自動管理，但它提供清除緩存的方法，這在大批量增加/更新操作是有效的。比如，同時增加十萬條記錄，按常規(guī)方式進行，很可能會發(fā)現(xiàn)OutofMemeroy的異常，這時可能需要手動清除這一級緩存：Session.evict以及Session.clear
c) 應用緩存：在一個SESSIONFACTORY中有效，因此也是優(yōu)化的重中之重，因此，各類策略也考慮的較多，在將數(shù)據(jù)放入這一級緩存之前，需要考慮一些前提條件：
i. 數(shù)據(jù)不會被第三方修改（比如，是否有另一個應用也在修改這些數(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中，且支持的緩存產品較少）
d) 分布式緩存：同c)的配置一樣，只是緩存產品的選用不同，在目前的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等）進行處理，很可能導致內存不夠的問題，而如果用基于游標（ScrollableResults）或Iterator的結果集，則不存在這樣的問題。
b) Session的load/get方法，前者會使用二級緩存，而后者則不使用。
c) Query和list/iterator，如果去仔細研究一下它們，你可能會發(fā)現(xiàn)很多有意思的情況，二者主要區(qū)別(如果使用了Spring，在HibernateTemplate中對應find,iterator方法)：
i. list只能利用查詢緩存（但在交易系統(tǒng)中查詢緩存作用不大），無法利用二級緩存中的單個實體，但list查出的對象會寫入二級緩存，但它一般只生成較少的執(zhí)行SQL語句，很多情況就是一條（無關聯(lián)）。
ii. iterator則可以利用二級緩存，對于一條查詢語句，它會先從數(shù)據(jù)庫中找出所有符合條件的記錄的ID，再通過ID去緩存找，對于緩存中沒有的記錄，再構造語句從數(shù)據(jù)庫中查出，因此很容易知道，如果緩存中沒有任何符合條件的記錄，使用iterator會產生N+1條SQL語句（N為符合條件的記錄數(shù)）
iii. ，如：
while(it.hasNext()){
YouObject object = (YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
}
如果用list方法，很可能就出OutofMemory錯誤了
iv. 通過上面的說明，我想你應該知道如何去使用這兩個方法了。
7、 集合的選用
8、 事務控制
事務方面對性能有影響的主要包括：事務方式的選用，事務隔離級別以及鎖的選用
a) 事務方式選用：如果不涉及多個事務管理器事務的話，不需要使用JTA，只有JDBC的事務控制就可以。
b) 事務隔離級別：參見標準的SQL事務隔離級別
c) 鎖的選用：悲觀鎖（一般由具體的事務管理器實現(xiàn)），對于長事務效率低，但安全。樂觀鎖（一般在應用級別實現(xiàn)），如在HIBERNATE中可以定義VERSION字段，顯然，如果有多個應用操作數(shù)據(jù)，且這些應用不是用同一種樂觀鎖機制，則樂觀鎖會失效。因此，針對不同的數(shù)據(jù)應有不同的策略，同前面許多情況一樣，很多時候我們是在效率與安全/準確性上找一個平衡點，無論如何，優(yōu)化都不是一個純技術的問題，你應該對你的應用和業(yè)務特征有足夠的了解。
9、 批量操作
即使是使用JDBC，在進行大批數(shù)據(jù)更新時，BATCH與不使用BATCH有效率上也有很大的差別。我們可以通過設置batch_size來讓其支持批量操作。
舉個例子，要批量刪除某表中的對象，如“delete Account”，打出來的語句，會發(fā)現(xiàn)HIBERNATE找出了所有ACCOUNT的ID，再進行刪除，這主要是為了維護二級緩存，這樣效率肯定高不了，在后續(xù)的版本中增加了bulk delete/update，但這也無法解決緩存的維護問題。也就是說，由于有了二級緩存的維護問題，HIBERNATE的批量操作效率并不盡如人意！
從前面許多要點可以看出，很多時候我們是在效率與安全/準確性上找一個平衡點，無論如何，優(yōu)化都不是一個純技術的問題，你應該對你的應用和業(yè)務特征有足夠的了解，一般的，優(yōu)化方案應在架構設計期就基本確定，否則可能導致沒必要的返工，致使項目延期，而作為架構師和項目經理，還要面對開發(fā)人員可能的抱怨，必竟，我們對用戶需求更改的控制力不大，但技術/架構風險是應該在初期意識到并制定好相關的對策。
還有一點要注意，應用層的緩存只是錦上添花，永遠不要把它當救命稻草，應用的根基（數(shù)據(jù)庫設計，算法，高效的操作語句，恰當API的選擇等）才是最重要的。