初用HIBERNATE的人也許都遇到過性能問題，實現同一功能，用HIBERNATE與用JDBC性能相差十幾倍很正常，如果不及早調整，很可能影響整個項目的進度。
大體上，對於HIBERNATE性能調優的主要考慮點如下:
* 數據庫設計調整
* HQL優化
* API的正確使用(如根據不同的業務類型選用不同的集合及查詢API)
* 主配置參數(日誌，查詢緩存，fetch_size, batch_size等)
* 映射文件優化(ID生成策略，二級緩存，延遲加載，關聯優化)
* 一級緩存的管理
* 針對二級緩存，還有許多特有的策略
* 事務控制策略。
1、 數據庫設計
a) 降低關聯的複雜性
b) 儘量不使用聯合主鍵
c) ID的生成機制，不同的數據庫所提供的機制並不完全一樣
d) 適當的冗餘數據，不過分追求高範式
2、 HQL優化
HQL如果拋開它同HIBERNATE本身一些緩存機制的關聯，HQL的優化技巧同普通的SQL優化技巧一樣，可以很容易在網上找到一些經驗之談。
- 批量數據操作時，Hibernate 3中的bulk delete/update能夠很大程度上提高操作的靈活性與運行效率
- 儘量使用通過select語句寫出需要查詢的屬性的方式來返回關係數據
- SQL語句優化
參見博客：http://blog.csdn.net/xdgofloadrunner/article/details/4131604
3、 主配置
a) 查詢緩存，同下面講的緩存不太一樣，它是針對HQL語句的緩存，即完全一樣的語句再次執行時可以利用緩存數據。但是，查詢緩存在一個交易系統(數據變更頻繁，查詢條件相同的機率並不大)中可能會起反作用:它會白白耗費大量的系統資源但卻難以派上用場。
b) fetch_size，同JDBC的相關參數作用類似，參數並不是越大越好，而應根據業務特徵去設置
設定JDBC的Statement讀取數據的時候每次從數據庫中取出的記錄條數
c) batch_size同上。
Batch Size是設定對數據庫進行批量刪除，批量更新和批量插入的時候的批次大小，有點相當於設置Buffer緩衝區大小的意思。
| hibernate.jdbc.fetch_size 50 hibernate.jdbc.batch_size 25 這兩個選項非常非常非常重要！！！將嚴重影響Hibernate的CRUD性能! C = create, R = read, U = update, D = delete Fetch Size 是設定JDBC的Statement讀取數據的時候每次從數據庫中取出的記錄條數。 例如一次查詢1萬條記錄，對於Oracle的JDBC驅動來說，是不會1次性把1萬條取出來的，而只會取出Fetch Size條數，當紀錄集遍歷完了這些記錄以後，再去數據庫取Fetch Size條數據。 因此大大節省了無謂的內存消耗。當然Fetch Size設的越大，讀數據庫的次數越少，速度越快；Fetch Size越小，讀數據庫的次數越多，速度越慢。 這有點像平時我們寫程序寫硬盤文件一樣，設立一個Buffer，每次寫入Buffer，等Buffer滿了以後，一次寫入硬盤，道理相同。 Oracle 數據庫的JDBC驅動默認的Fetch Size=10，是一個非常保守的設定，根據我的測試，當Fetch Size=50的時候，性能會提升1倍之多，當Fetch Size=100，性能還能繼續提升20%，Fetch Size繼續增大，性能提升的就不顯著了。 因此我建議使用Oracle的一定要將Fetch Size設到50。 不過並不是所有的數據庫都支持Fetch Size特性，例如MySQL就不支持。 MySQL就像我上面說的那種最壞的情況，他總是一下就把1萬條記錄完全取出來，內存消耗會非常非常驚人！這個情況就沒有什麼好辦法了 :( Batch Size是設定對數據庫進行批量刪除，批量更新和批量插入的時候的批次大小，有點相當於設置Buffer緩衝區大小的意思。 Batch Size 越大，批量操作的向數據庫發送sql的次數越少，速度就越快。我做的一個測試結果是當Batch Size=0的時候，使用Hibernate對 Oracle數據庫刪除1萬條記錄需要25秒，Batch Size = 50的時候，刪除僅僅需要5秒！！！ 可見有多麼大的性能提升！很多人做Hibernate和JDBC的插入性能測試會奇怪的發現Hibernate速度至少是JDBC的兩倍，就是因爲Hibernate使用了Batch Insert，而他們寫的JDBC沒有使用Batch的緣故。 以我的經驗來看，Oracle數據庫 Batch Size = 30 的時候比較合適，50也不錯，性能會繼續提升，50以上，性能提升的非常微弱，反而消耗內存更加多，就沒有必要了。 |
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方法。
１．如果找不到符合條件的紀錄，get()方法將返回null．而load()將會報出ObjectNotFoundException．
２．load()方法可以返回實體的代理類實例，而get()永遠只返回實體類．
３．load()方法可以充分利用二級緩存和內部緩存的現有數據，而get()方法只在內部緩存中進行查找，如沒有發現對應數據將跳過二級緩存，直接調用ＳＱＬ完成查找．
見：http://blog.csdn.net/nuoyan666/article/details/4620505
c) Query和list/iterator，如果去仔細研究一下它們，你可能會發現很多有意思的情況，二者主要區別(如果使用了Spring，在HibernateTemplate中對應find,iterator方法):
i. list只能利用查詢緩存(HQL緩存，但在交易系統中查詢緩存作用不大)，無法利用二級緩存中的單個實體，但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.evict(YouObject.class, youObject.getId());//將某個類的指定ID的持久化對象從二級緩存中清除,釋放對象所佔用的資源.
}
如果用list方法，很可能就出OutofMemory錯誤了。
iv. 通過上面的說明，我想你應該知道如何去使用這兩個方法了。
7、 集合的選用
在HIBERNATE 3.1文檔的“19.5. Understanding Collection performance”中有詳細的說明。
參見博客：http://iceside.iteye.com/blog/1047967
8、 事務控制
事務方面對性能有影響的主要包括:事務方式的選用，事務隔離級別以及鎖的選用
a) 事務方式選用:如果不涉及多個事務管理器事務的話，不需要使用JTA，只有JDBC的事務控制就可以。
b) 事務隔離級別:參見標準的SQL事務隔離級別
c) 鎖的選用:悲觀鎖(一般由具體的事務管理器實現)，對於長事務效率低，但安全。樂觀鎖(一般在應用級別實現)，如在HIBERNATE中可以定義VERSION字段，顯然，如果有多個應用操作數據，且這些應用不是用同一種樂觀鎖機制，則樂觀鎖會失效。因此，針對不同的數據應有不同的策略，同前面許多情況一樣，很多時候我們是在效率與安全/準確性上找一個平衡點，無論如何，優化都不是一個純技術的問題，你應該對你的應用和業務特徵有足夠的瞭解。
9、 批量操作
即使是使用JDBC，在進行大批數據更新時，BATCH與不使用BATCH有效率上也有很大的差別。我們可以通過設置batch_size來讓其支持批量操作。
舉個例子，要批量刪除某表中的對象，如“delete Account”，打出來的語句，會發現HIBERNATE找出了所有ACCOUNT的ID，再進行刪除，這主要是爲了維護二級緩存，這樣效率肯定高不了，在後續的版本中增加了bulk delete/update，但這也無法解決緩存的維護問題。也就是說，由於有了二級緩存的維護問題，HIBERNATE的批量操作效率並不盡如人意!