Spring Data JPA Pageable在悲观锁查询中未生效？日志显示提取500行

核心结论 #

是的，从PostgreSQL日志的Extracted JDBC value [0] - [500]可以判断：分页逻辑未生效，单次事务确实获取了全部500条ID为偶数的行（1000行数据中ID为偶数的恰好是500条）。

分页失效的常见原因 #

1. 查询方法返回类型错误
   如果你的Repository方法返回的是List<Tab>而非Page<Tab>，Spring Data JPA可能会跳过SQL层面的分页，转而在内存中对全量查询结果做分页。这种情况下日志仍会显示全量数据被加载到内存，和你遇到的现象一致。

2. 自定义SQL未绑定分页参数
   若你使用@Query自定义查询语句，但未在SQL中添加分页相关的LIMIT和OFFSET，框架无法自动生成分页逻辑，会直接查询所有符合条件的行。比如错误的自定义SQL：

   @Lock(LockModeType.PESSIMISTIC_WRITE)
   @Query("SELECT t FROM Tab t WHERE t.id % 2 = 0")
   List<Tab> findEvenIdTabs(Pageable pageable); // 无分页参数绑定，返回全量结果
   

3. 悲观锁与分页的兼容问题
   部分场景下，Spring Data JPA处理@Lock(LockModeType.PESSIMISTIC_WRITE)时，会优先执行全量查询获取行锁，再做内存分页。这种情况通常发生在查询逻辑依赖复杂关联或自定义结果转换时。

修复方案 #

1. 确保正确的查询方法定义 #

使用Page<Tab>作为返回类型，让框架自动生成带分页的SQL：

public interface TabRepository extends JpaRepository<Tab, Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    Page<Tab> findByIdEven(Pageable pageable);
}

注：findByIdEven是Spring Data JPA的推导查询，会自动匹配id % 2 = 0的条件

2. 自定义SQL时绑定分页参数 #

如果必须使用自定义@Query，需显式添加分页参数：

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query(value = "SELECT t FROM Tab t WHERE t.id % 2 = 0",
       countQuery = "SELECT COUNT(t) FROM Tab t WHERE t.id % 2 = 0")
Page<Tab> findEvenIdTabs(Pageable pageable);

框架会自动将Pageable中的size和offset转换为SQL的LIMIT和OFFSET。

3. 验证生成的SQL #

开启Spring Data JPA的SQL日志（spring.jpa.show-sql=true），确认执行的SQL包含LIMIT 50 OFFSET 0（对应你需要的50条数据）和FOR UPDATE锁语句。正确的SQL示例：

SELECT t.id, t.checked, ... FROM tab t WHERE t.id % 2 = 0 LIMIT 50 OFFSET 0 FOR UPDATE

4. 事务内完成锁定与更新 #

在同一个事务中执行查询锁定和更新操作，避免锁失效：

@Service
@Transactional
public class TabService {
    private final TabRepository tabRepository;

    public void updateCheckedForEvenIds() {
        Pageable pageable = PageRequest.of(0, 50);
        Page<Tab> tabPage = tabRepository.findByIdEven(pageable);
        
        tabPage.getContent().forEach(tab -> tab.setChecked(true));
        tabRepository.saveAll(tabPage.getContent());
    }
}

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