Performance Hibernate适合批处理吗？内存使用情况如何？

我每天都有一个批处理过程，包括选择大量记录并格式化一个文件以发送到外部系统。我还需要将这些记录标记为已发送，以便明天不再传输

以我天真的JDBC方式，我准备并执行一条语句，然后开始循环记录集。由于我只向前遍历记录集，因此我的应用服务器不需要一次将整个结果集保存在内存中。记录组可以从数据库服务器传送

---

现在，假设我正在使用hibernate。我不会一次在内存中得到一堆表示整个结果集的对象吗？

Hibernate也会迭代结果集，因此内存中只保留一行。这是默认设置。如果它贪婪地装载，你必须告诉它

使用Hibernate的原因：

• “某人”的列名是“创造性的”（PRXFC0315.XXFZZCC12）
• DB设计仍在不断变化，并且/或者您希望在一个地方将列名映射到Java
• 你还是在用Hibernate
• 您有复杂的查询，并且SQL不流利

不使用Hibernate的原因：

• 应用程序的其余部分是纯JDBC
• 你不需要任何冬眠的力量
• 您有复杂的查询，并且能够流利地使用SQL
• 您需要数据库的特定功能来执行SQL

---

在我看来，我不想使用Hibernate，因为它会使应用程序变得更大、更不易维护，而且您实际上没有机会快速优化生成的sql脚本。 此外，您可以使用JDBC桥支持的所有SQL功能，而不限于hibernate功能。另一件事是，每一层遗留代码都有其局限性

---

但最终这是一个哲学问题，你应该按照你认为最好的方式去做。

如果有可能的性能问题，那么坚持使用JDBC代码

有许多众所周知的纯SQL优化 这在冬眠状态下是很难做到的

仅选择您使用的列！（无“选择*”内容）

让SQl尽可能简单。e、 g.不要在连接中包含货币代码之类的小参考表。而是将货币表加载到内存中，并通过程序查找来解析货币描述

根据数据库管理系统的不同，SQL语句的次要重新排序会对性能产生重大影响

如果您正在更新/插入，请仅每100到1000次更新提交一次。i、 e.不要承诺每一个工作单元，但要保留一些计数器，以便减少承诺的频率

---

利用数据库的聚合功能。如果您想要按部门代码进行汇总，那么可以在SQL中使用“汇总（金额）…按部门分组”进行汇总。

Hibernate，因为任何ORM框架都旨在基于面向对象编程原理开发和维护系统。但是大多数数据库都是关系型的，而不是面向对象的，因此在任何情况下，ORM总是在方便的OOP编程和优化/最有效的数据库访问之间进行权衡

---

我不会将ORM用于特定的独立任务，而是作为应用程序持久性层的总体架构选择。

Hibernate提供了一些保持会话小型化的可能性

---

您可以使用Query.scroll（）、Criteria.scroll（）进行类似JDBC的滚动。您可以使用Session.execute（对象实体）从会话中删除实体。您可以使用无状态会话来禁止脏检查。还有更多的性能优化，请参阅Hibernate文档。

在Hibernate中更改投影非常容易，您可以获取关系结果网格的列表建模，或者让Hibernate使用本机SQL或HQL为您实例化特定对象。聚合函数和分组依据在CriteriaAPI和HQL中也可用。