分页不适用于春季批处理中的 JpaPagingItemReader 和 jpql 请求答案

【问题标题】：Pagination doesn't work with JpaPagingItemReader and jpql request in spring batch分页不适用于春季批处理中的 JpaPagingItemReader 和 jpql 请求
【发布时间】：2020-09-06 18:10:07
【问题描述】：

我有一个无法解决的问题。我使用 PostGreSql 和 Spring 批处理，特别是 jpaPagingItemReader 来读取我的数据库，并在 JPA 中进行分页。为了优化性能，我还使用分区器在分区中读取我的数据库。所以每个分区都会使用 jpaPagingItemReader 从数据库中读取相关的区间。由于我的基本 id 不是连续的，因此分区程序会使用 id 列表创建分区。

所以 JpaPagingItemReader 做了一个 SELECT c FROM Entity c WHERE c.id IN: ids 用一个 pageSize (10) 和一个 parameterValues 包含 ids 到分区给出的 ids 列表中。我的 pageSize 的值等于我的块的值。

这就是我的问题所在，如下所示。我的分区可能包含一个非常大的 id 列表，所以我有时会收到错误 "java.io.IOException: Tried to send an out-of-range integer as a 2-byte value" 这是有道理的，因为我在技术上超过了 PostGreSql 在结果集中允许的最大值。我不明白的是分页应该避免这个问题，因为我将 JpaPagingItemReader 的页面大小设置为 10。

另一方面，对于相同的分区列表，当我的 JpaPagingItemReader 采用像 SELECT c FROM Entity c WHERE c.id IN (id1, id2, id3, ..., idn) 这样的本机查询时，具有相同的页面大小 (10)，批处理开始良好并且处理完成时没有PostGreSql 错误。

好像分页在 jpql 上不起作用，而是在 nativesql 上起作用。

可能是我的分析错了。

请帮忙。

【问题讨论】：

标签： postgresql jpa pagination spring-batch partitioning

【解决方案1】：

我想说这个问题与分页或响应大小无关，而是与请求本身有关。 PostgreSql 对每个语句 (32767) 的绑定变量数量有限制，并且 IN 子句超出了该数量。你可以通过限制分区大小来解决它。

【讨论】：

是的，我知道 PostgreSql 有一个每个查询变量的限制 (32767)。但是不应该为页面设置大小限制查询中的变量数量吗？提醒一下，这个问题只出现在JpaPagingItemReader的queryString是jpql而不是sql的时候。为什么当我使用分区大小大于 PostgreSql 设置的限制的本机查询时不会出现问题？
为什么页面大小要限制变量个数？他们是无关的。如果数据库中不存在某些变量怎么办？
据我了解，“本机查询”不会出现问题，因为 id 直接包含在查询中，因此不涉及绑定。