java:ResultSet迭代与列表迭代：性能有差异吗

我必须制作一个报告实用程序，它从一个非常旧的大型表中获取数据。我的搜索条件将一次取出一百万条记录，这些记录稍后将用于一些垃圾IO操作。我可以选择使用JDBC，它会给我一个结果集，或者使用Hibernate，它会给我一个列表。我想知道在迭代过程中，两者之间是否会有性能差异

这取决于：

• 休眠版本
• 数据库管理系统及其版本
• JDBC驱动程序和版本

它的工作原理是：如果您使用以下内容创建

语句

s：

PreparedStatement stmt = con.prepareStatement(sql,
                                              ResultSet.TYPE_FORWARD_ONLY,
                                              ResultSet.CONCUR_READ_ONLY);

然后，体面的DBMS/驱动程序将流式处理大查询，而内存影响将很小，代价是保持

连接的时间更长。如果您使用Hibernate获得一个大查询的
列表
，它将尝试立即将整个结果集加载到内存中，如果GC启动，整个过程最多只能爬行，最坏的情况下会崩溃。因此，对于大型结果集，JDBC将是更好的选择

现在，如果您不介意在Hibernate中使用
列表
，您可以使用。请参阅：即使该方法不适用于该特定情况，该技术也将适用于JDBC方法可以正常工作的每个DBMS/驱动程序组合（毕竟它只是上述纯JDBC方法上的一个薄薄的Hibernate层）。您还可以使用Hibernate的ORM部分。
Hibernate需要通过结果集来构建该列表，那么您认为呢？但是，您更应该关注的是您的查询，而不是结果的迭代。我在本地计算机上做了一些测试，当为大量记录调用query.list（）时，hibernate确实花费了大量时间。我必须想出一个更好的解决方案。如果你将要做的操作是合适的，你应该在迭代时执行它们（即以流式方式）。这可能不合适，但比先读取内存中的所有数据，然后再处理它们要快。可能的重复称之为共事件。。。我通过将Resultset设置为Type_forward和Concor_read，对PrePrePredStatement应用了相同的方法。我也尝试了使用无状态会话的ScrollableResults，但感觉像是强迫自己使用Hibernate，所以我选择了通用JDBC。为了避免任何内存问题，我将记录成束，一次2万条，然后执行IO操作。这有点慢，但消除了OutOfMeMoy错误的风险