java - JDBC分页: vendor specific sql versus result set fetchSize

Question

互联网上有很多关于使用 JDBC 分页/对巨大结果集进行迭代的不同教程。所以，基本上到目前为止我发现了很多方法:

1. Vendor specific sql
2. 可滚动结果集 (?)
3. 将纯结果集保存在内存中，并仅在必要时映射行(使用 fetchSize)

   The result set fetch size, either set explicitly, or by default equal to the statement fetch size that was passed to it, determines the number of rows that are retrieved in any subsequent trips to the database for that result set. This includes any trips that are still required to complete the original query, as well as any refetching of data into the result set. Data can be refetched, either explicitly or implicitly, to update a scroll-sensitive or scroll-insensitive/updatable result set.

4. 光标(？)
5. Custom seek method paging implemented by jooq

抱歉搞乱了所有这些，但我需要有人帮我解决这个问题。我有一个简单的任务，服务使用者请求带有 pageNumber 和 pageSize 的结果。看起来我有两个选择:

1. 使用供应商特定的 SQL
2. 将连接/语句/结果集保存在内存中并依赖jdbc fetchSize

在后一种情况下，我使用 rxJava-jdbc如果你看 producer implementation它保存结果集，然后您所做的就是调用 request(long n) 并处理另外 n 行。当然，一切都隐藏在 rxJava 的 Observable 糖之下。我不喜欢这种方法的是，您必须在不同的服务调用之间保存结果集，并且如果客户端忘记耗尽或关闭它，则必须清除该结果集。 (注:这里的resultSet是java ResultSet类，不是实际的数据)

那么，推荐的分页方式是什么？与保持连接相比，供应商特定的 SQL 是否被认为较慢？

我使用的是oracle，ScrollableResultSet不建议与巨大的结果集一起使用，因为它会在客户端缓存整个结果集数据。 proof

Answer 1

一般来说，无限期地保持资源开放是一件坏事。例如，数据库将创建一个游标供您获取所提取的行。该游标和其他资源将保持打开状态，直到您关闭结果集。并行执行的查询越多，占用的资源就越多，在某些时候，数据库将由于资源池耗尽而拒绝进一步的请求(例如，一次可以打开的游标数量有限)。

例如，Hibernate 使用供应商特定的 SQL 来获取“页面”，我会这样做。