当 Spring Batch 的 RepositoryItemReader 在分页读取过程中动态修改其查询条件（如 IS_UPDATED = true）时，会导致后续分页跳过部分记录；根本原因是分页依赖数据库排序与偏移量，而数据状态变更破坏了分页一致性。
当 spring batch 的 `repositoryitemreader` 在分页读取过程中动态修改其查询条件（如 `is_updated = true`）时，会导致后续分页跳过部分记录；根本原因是分页依赖数据库排序与偏移量，而数据状态变更破坏了分页一致性。
在 Spring Batch 中，若使用基于分页（如 PagingAndSortingRepository + RepositoryItemReader）的方式读取数据，并同时在 Writer 阶段更新影响 Reader 查询条件的字段（例如将 IS_UPDATED = true 改为 false），将引发数据漏读问题。典型场景如下：
- 数据库共 6 条记录（A–F），均满足 IS_UPDATED = true；
- 分页大小设为 2，首次读取第 1 页 → 返回 A、B；
- Writer 执行后将 A、B 的 IS_UPDATED 设为 false；
- 第二次读取第 2 页时，因数据库中剩余 IS_UPDATED = true 的记录已变为 C、D、E、F，但分页逻辑仍按原始全集的第 2 页（即第 3–4 条）定位——而由于 A、B 状态变更，实际排序可能偏移，最终可能跳过 C、D，直接读到 E、F。
⚠️ 根本原因：RepositoryItemReader 依赖 Pageable 进行分页，其底层通过 LIMIT/OFFSET 或 ROW_NUMBER() 实现，要求分页期间数据集稳定。一旦 Writer 修改了 Reader 的过滤谓词字段（如 IS_UPDATED），分页边界失效，结果不可预测。
✅ 正确解法：改用 JdbcCursorItemReader（游标式读取）
JdbcCursorItemReader 基于 JDBC ResultSet 的游标遍历，不依赖分页参数，而是顺序扫描符合 WHERE IS_UPDATED = true 的全部结果集——无论 Writer 是否更新中间状态，只要 SQL 查询结果集在打开游标时已确定，就能保证全量、有序、无遗漏处理。
示例配置：
@Bean
public JdbcCursorItemReader<myentity> cursorItemReader(DataSource dataSource) {
return new JdbcCursorItemReaderBuilder<myentity>()
.name("cursorItemReader")
.dataSource(dataSource)
.sql("SELECT id, name, is_updated FROM my_table WHERE is_updated = true ORDER BY id")
.rowMapper(new BeanPropertyRowMapper(MyEntity.class))
.build();
}</myentity></myentity>
? 关键注意事项：
- 必须在 SQL 中显式添加 ORDER BY（如 ORDER BY id），确保游标遍历顺序稳定；
- 不支持多线程并发读取同一游标（JdbcCursorItemReader 本身非线程安全），若需并行处理，请改用 JdbcPagingItemReader + 稳定分片键（如 id BETWEEN ? AND ?），或采用 分区 Step（PartitionStep），为每个线程分配互斥的数据子集；
- 若坚持使用多线程，应避免在 Reader 查询条件中依赖易变状态字段；推荐改用时间戳（如 last_modified
总结：分页读取与就地状态更新存在本质冲突。RepositoryItemReader 适用于只读场景；一旦涉及“读—处理—标记”闭环，务必切换至游标读取或设计幂等、可分片的读取策略，才能保障 Spring Batch 的数据完整性与可重复性。
