Spring Boot Batch DB2数据源分页读取仅取第一页异常

核心参数的实际作用边界 #

首先要明确三个参数是完全解耦的，不存在互相嵌套的换算关系：

• pageSize：JdbcPagingItemReader 的核心分页粒度，决定了每一次触发数据库查询时，从结果集中拉取的单页记录数量。Reader 会循环执行带偏移条件的分页查询，直到某一页返回空结果才会终止，本身不会设置全局读取量上限。
• fetchSize：纯JDBC驱动层面的游标预取参数，作用是告知数据库驱动，当从服务端结果集游标读取数据时，单次网络交互拉取多少行数据到客户端内存。这个参数完全不参与Spring Batch的分页次数、总读取量的计算逻辑，哪怕配置再大，也不会改变Reader的分页循环规则。
• chunkSize：Step层面的事务提交粒度，和Reader的分页逻辑完全解耦。Reader返回的单页数据会被逐块拆分为chunkSize大小的批次，每完成一个批次的处理、写入后就提交一次事务，和pageSize没有强制对齐要求。

作业仅读取4万条就终止的根本原因 #

你观察到SQL被追加FETCH FIRST 40000 ROWS ONLY是正常分页语法，但出现提前终止的核心原因是：
当前使用的PagingQueryProvider没有正确生成带偏移条件的后续分页SQL。
正常的DB2分页逻辑生成的SQL应该是：

1. 首次查询：SELECT * FROM 表名 ORDER BY 排序键 ASC FETCH FIRST {pageSize} ROWS ONLY
2. 第二次及后续翻页查询：自动拼接上一页最后一条记录的排序键值作为WHERE过滤条件，例如SELECT * FROM 表名 WHERE 排序键 > {上一页最后一条的排序键值} ORDER BY 排序键 ASC FETCH FIRST {pageSize} ROWS ONLY
   如果PagingQueryProvider没有正确识别DB2的分页语法、或者没有配置全局唯一的排序键，就会导致所有分页查询都不带偏移条件，第一次查询返回4万行后，第二次查询依然返回最前面的4万行，Reader会触发重复分页校验，直接判定没有更多数据、终止读取流程。
   注意：你之前的认知误区是把fetchSize当成总检索量，这个逻辑不存在于任何Spring Batch的源码实现中，无论fetchSize配多大，都不会限制Reader的总读取范围。

面向十万/百万级数据的高性能配置方案 #

1. 修正PagingQueryProvider配置
   替换通用的QueryProvider为DB2专属实现，显式指定带索引的唯一排序键，确保分页SQL能正确生成翻页条件，示例代码：

   @Bean
   public PagingQueryProvider db2PagingQueryProvider() throws Exception {
       Db2PagingQueryProvider provider = new Db2PagingQueryProvider();
       provider.setSelectClause("SELECT ID, TRANS_AMOUNT, TRANS_TIME FROM BIZ_TRANS");
       provider.setFromClause("FROM BIZ_TRANS");
       // 必须指定有数据库索引的唯一字段作为排序键，避免分页错位
       Map<String, Order> sortKeys = new HashMap<>();
       sortKeys.put("ID", Order.ASCENDING);
       provider.setSortKeys(sortKeys);
       return provider;
   }
   

2. 参数合理配比（适配DB2 AS400环境）
   • pageSize：调整为1000~5000。不要配置4万的大值——JdbcPagingItemReader会把单页的所有记录一次性加载到JVM内存中，pageSize过大会导致内存占用飙升，拉长单次数据库查询的锁持有时间。
   • fetchSize：设置为pageSize的1~2倍即可。比如pageSize=5000时，fetchSize=10000就可以最大化利用JDBC游标预取能力，减少网络交互次数，同时避免驱动拉取多余的无效数据浪费资源。
   • chunkSize：设置为1000~2000。Chunk是事务提交的最小粒度，过大的chunk会拉长事务持有时间、增大回滚段占用；过小的chunk会导致事务提交过于频繁，降低写入性能。
3. 百万级数据优化提示
   • 确保排序键在数据库层有覆盖索引，避免分页查询触发全表扫描
   • 将Reader的saveState配置为true，作业异常中断后可以从上次的分页位置续跑，不需要全量重跑
   • 异步多线程处理场景下，只要分页逻辑正确，JdbcPagingItemReader不会出现漏读、重复读的问题

内容的提问来源于stack exchange，提问作者Joseph Freeman