初用 HIBERNATE 的人也許都遇到過性能問題，實現同一功能，用 HIBERNATE 與用 JDBC 性能相差十幾倍很正常，如果不及早調整，很可能影響整個項目的進度。
大體上，對於 HIBERNATE 性能調優的主要考慮點如下 :
•數據庫設計調整
•HQL 優化
•API 的正確使用 ( 如根據不同的業務類型選用不同的集合及查詢 API)
•主配置參數 ( 日誌，查詢緩存， fetch_size, batch_size 等 )
•映射文件優化 (ID 生成策略，二級緩存，延遲加載，關聯優化 )
•一級緩存的管理
•針對二級緩存，還有許多特有的策略
•事務控制策略。
1 、 數據庫設計
a) 降低關聯的複雜性
b) 儘量不使用聯合主鍵
c) ID 的生成機制，不同的數據庫所提供的機制並不完全一樣
d) 適當的冗餘數據，不過分追求高範式
2 、 HQL 優化
HQL 如果拋開它同 HIBERNATE 本身一些緩存機制的關聯， HQL 的優化技巧同普通的 SQL 優化技巧一樣，可以很容易在網上找到一些經驗之談。
3 、 主配置
a) 查詢緩存，同下面講的緩存不太一樣，它是針對 HQL 語句的緩存，即完全一樣的語句再次執行時可以利用緩存數據。但是，查詢緩存在一個交易系統 ( 數據變更頻繁，查詢條件相同的機率並不大 ) 中可能會起反作用 : 它會白白耗費大量的系統資源但卻難以派上用場。
b) fetch_size ，同 JDBC 的相關參數作用類似，參數並不是越大越好，而應根據業務特徵去設置
c) batch_size 同上。
d) 生產系統中，切記要關掉 SQL 語句打印。
4 、 緩存
a) 數據庫級緩存 : 這級緩存是最高效和安全的，但不同的數據庫可管理的層次並不一樣，比如，在 ORACLE 中，可以在建表時指定將整個表置於緩存當中。
b) SESSION 緩存 : 在一個 HIBERNATE SESSION 有效，這級緩存的可干預性不強，大多於 HIBERNATE 自動管理，但它提供清除緩存的方法，這在大批量增加 / 更新操作是有效的。比如，同 時增加十萬條記錄，按常規方式進行，很可能會發現 OutofMemeroy 的異常，這時可能需要手動清除這一級緩存 :Session.evict 以及 Session.clear
c) 應用緩存 : 在一個 SESSIONFACTORY 中有效，因此也是優化的重中之重，因此，各類策略也考慮的較多，在將數據放入這一級緩存之前，需要考慮一些前提條件 :
i. 數據不會被第三方修改 ( 比如，是否有另一個應用也在修改這些數據 ?)
ii. 數據不會太大
iii. 數據不會頻繁更新 ( 否則使用 CACHE 可能適得其反 )
iv. 數據會被頻繁查詢
v. 數據不是關鍵數據 ( 如涉及錢，安全等方面的問題 ) 。
緩存有幾種形式，可以在映射文件中配置 :read-only( 只讀，適用於很少變更的靜態數據 / 歷史數據 ) ， nonstrict-read-write ， read-write( 比較普遍的形式，效率一般 ) ， transactional(JTA 中，且支持的緩存產品較少 )
d) 分佈式緩存 : 同 c) 的配置一樣，只是緩存產品的選用不同，在目前的 HIBERNATE 中可供選擇的不多， oscache, jboss cache ，目前的大多數項目，對它們的用於集羣的使用 ( 特別是關鍵交易系統 ) 都持保守態度。在集羣環境中，只利用數據庫級的緩存是最安全的。
5 、 延遲加載
a) 實體延遲加載 : 通過使用動態代理實現
b) 集合延遲加載 : 通過實現自有的 SET/LIST ， HIBERNATE 提供了這方面的支持
c) 屬性延遲加載 :
6 、 方法選用
a) 完成同樣一件事， HIBERNATE 提供了可供選擇的一些方式，但具體使用什麼方式，可能用性能 / 代碼都會有影響。顯示，一次返回十萬條記錄 (List/Set/Bag/Map 等 ) 進行處理，很可能導致內存不夠的問題，而如果用基於遊標 (ScrollableResults) 或 Iterator 的結果集，則不存在這樣的問題。
b) Session 的 load/get 方法，前者會使用二級緩存，而後者則不使用。
c) Query 和 list/iterator ，如果去仔細研究一下它們，你可能會發現很多有意思的情況，二者主要區別 ( 如果使用了 Spring ，在 HibernateTemplate 中對應 find,iterator 方法 ):
i. list 只能利用查詢緩存 ( 但在交易系統中查詢緩存作用不大 ) ，無法利用二級緩存中的單個實體，但 list 查出的對象會寫入二級緩存，但它一般只生成較少的執行 SQL 語句，很多情況就是一條 ( 無關聯 ) 。
ii. iterator 則可以利用二級緩存，對於一條查詢語句，它會先從數據庫中找出所有符合條件的記錄的 ID ，再通過 ID 去緩存找，對於緩存中沒有的記錄，再 構造語句從數據庫中查出，因此很容易知道，如果緩存中沒有任何符合條件的記錄，使用 iterator 會產生 N+1 條 SQL 語句 (N 爲符合條件的記錄數 )
iii. 通過 iterator ，配合緩存管理 API ，在海量數據查詢中可以很好的解決內存問題，如 :
while(it.hasNext()){
YouObject object = (YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
}
如果用 list 方法，很可能就出 OutofMemory 錯誤了。
iv. 通過上面的說明，我想你應該知道如何去使用這兩個方法了。
7 、 集合的選用
在 HIBERNATE 3.1 文檔的“ 19.5. Understanding Collection performance” 中有詳細的說明。
8 、 事務控制
事務方面對性能有影響的主要包括 : 事務方式的選用，事務隔離級別以及鎖的選用
a) 事務方式選用 : 如果不涉及多個事務管理器事務的話，不需要使用 JTA ，只有 JDBC 的事務控制就可以。
b) 事務隔離級別 : 參見標準的 SQL 事務隔離級別
c) 鎖的選用 : 悲觀鎖 ( 一般由具體的事務管理器實現 ) ，對於長事務效率低，但安全。樂觀鎖 ( 一般在應用級別實現 ) ，如在 HIBERNATE 中可以定義 VERSION 字段，顯然，如果有多個應用操作數據，且這些應用不是用同一種樂觀鎖機制，則樂觀鎖會失效。因此，針對不同的數據應有不同的策略，同前面許 多情況一樣，很多時候我們是在效率與安全 / 準確性上找一個平衡點，無論如何，優化都不是一個純技術的問題，你應該對你的應用和業務特徵有足夠的瞭解。
9 、 批量操作
即使是使用 JDBC ，在進行大批數據更新時， BATCH 與不使用 BATCH 有效率上也有很大的差別。我們可以通過設置 batch_size 來讓其支持批量操作。
舉個例子，要批量刪除某表中的對象，如“ delete Account” ，打出來的語句，會發現 HIBERNATE 找出了所有 ACCOUNT 的 ID ，再進行刪除，這主要是爲了維護二級緩存，這樣效率肯定高不 了，在後續的版本中增加了 bulk delete/update ，但這也無法解決緩存的維護問題。也就是說，由於有了二級緩存的維護問題， HIBERNATE 的批量操作效率並不盡如人意 !
從 前面許多要點可以看出，很多時候我們是在效率與安全 / 準確性上找一個平衡點，無論如何，優化都不是一個純技術的問題，你應該對你的應用和業務特徵有足夠的 瞭解，一般的，優化方案應在架構設計期就基本確定，否則可能導致沒必要的返工，致使項目延期，而作爲架構師和項目經理，還要面對開發人員可能的抱怨，必 竟，我們對用戶需求更改的控制力不大，但技術 / 架構風險是應該在初期意識到並制定好相關的對策。
還有一點要注意，應用層的緩存只是錦上添花，永遠不要把它當救命稻草，應用的根基 ( 數據庫設計，算法，高效的操作語句，恰當 API 的選擇等 ) 纔是最重要的。