我有一個每日批處理過程，包括選擇大量記錄並格式化文件發送到外部系統。我還需要將這些記錄標記爲已發送，以便明天不再發送。Hibernate是否適合批處理？內存使用情況如何？
以我幼稚的JDBC方式，我會準備並執行一條語句，然後開始循環訪問記錄集。由於我只通過記錄集轉發，因此我的應用程序服務器不需要一次將整個結果集保存在內存中。記錄組可以從數據庫服務器提供。
現在，讓我說我正在使用休眠。我不會最終與一堆代表整個結果集的對象一起存儲在內存中嗎？
Hibernate也迭代結果集，所以只有一行保留在內存中。這是默認設置。如果它貪婪地加載，你必須這樣說。
原因使用Hibernate：
原因不使用Hibernate：
在我看來我就不使用Hibernate，因爲它使你的應用程序一大堆更大，少維護，你真的不可以快速優化生成的sql腳本。 此外，您可以使用JDBC橋支持的所有SQL功能，並且不限於休眠功能。另一件事是你也有與每層遺留代碼一起出現的侷限性。
但最終這是一個哲學問題，你應該這樣做，它適合你的方式是最好的思維方式。
如果存在可能的性能問題，請使用JDBC代碼。
有一些衆所周知的純SQL優化，其中 這將是非常困難的在Hibernate做。
只選擇您使用的列！ （沒有「選擇*」的東西）。
保持SQl儘可能簡單。例如不要在連接中包含貨幣代碼等小型參考表。而是將貨幣表加載到內存中，並使用程序查找來解析貨幣描述。
取決於DBMS對SQL的次要重新排序，其中謂詞可能會對性能產生重大影響。
如果您更新/插入僅提交每100到1000次更新。即不要犯下每個工作單元，但要保留一些計數器，這樣你就不那麼經常犯下錯誤。
利用數據庫的聚合函數。如果你想要DEPT代碼的總數，那麼在SQL中用「SUM（amount）... GROUP BY DEPT」來完成。
作爲任何ORM框架的Hibernate旨在用於開發和維護基於面向對象編程原理的系統。但是大多數數據庫都是關係型的而不是面向對象的，所以在任何情況下，ORM總是在方便的OOP編程和優化/最有效的DB訪問之間進行權衡。
我不會將ORM用於特定的獨立任務，而是作爲應用程序持久層的整體架構選擇。
休眠提供了一些可能性，以保持會話小。
您可以使用Query.scroll（），Criteria.scroll（）進行類似於JDBC的滾動。您可以使用Session.evict（對象實體）從會話中刪除實體。您可以使用StatelessSession來禁止髒檢查。還有更多的性能優化，請參閱Hibernate文檔。
在Hibernate中更改投影非常簡單，您可以返回列表建模關係結果網格，或讓Hibernate使用原生SQL或HQL爲您實例化特定對象。 集合函數和GROUP BY也可在Criteria API和HQL中使用。 –
2009-07-27 10:10:56