JPA复合主键场景下OneToMany关联查询结果错误问题

这是JPA懒加载关联的标准行为导致的结果，不是框架bug：

1. 你观察到的第一条SQL确实符合预期：派生查询里的条件已经正确拼接，筛选出了匹配sId和关联activityId的TableA主记录。
2. 你的@OneToMany关联默认使用FetchType.LAZY懒加载策略，当你访问返回结果中TableA对象的tableb集合时，JPA会触发第二条SQL加载关联数据。这第二条SQL是JPA默认的关联集合加载逻辑，仅以外键roleNo作为查询条件，会把当前TableA下所有关联的TableB记录全部查出，完全不会继承你派生查询里写的activityId过滤条件，所以最终拿到的关联数据是全量的，不符合预期。
3. 额外提示代码里的两处小问题：
   • TableB实体里的@EmbededId拼写错误，正确注解为@EmbeddedId
   • 复合主键类CKStudent里的属性名ActivityId不符合Java驼峰命名规范，建议统一改成小驼峰activityId，避免派生查询解析时出现字段名匹配错误。

根据业务场景二选一即可： #

方案1：自定义JPQL查询（动态参数场景首选） #

这是最适配你当前需求的方案，直接在Repository接口中用@Query写JPQL，通过fetch join一次性加载过滤后的关联数据，不会生成额外SQL：

@Repository
public interface TableARepository extends JpaRepository<TableA, Integer> {
    @Query("select distinct a from TableA a " +
           "left join fetch a.tableb b " +
           "where a.sId = :sid and b.student.activityId = :activityId")
    List<TableA> getFilteredTableA(@Param("sid") Integer sid, @Param("activityId") Integer activityId);
}

注意必须加distinct关键字，否则联表查询会返回重复的TableA对象。
该写法最终只会生成一条带完整过滤条件的联表SQL，返回的tableb集合就是经过activityId过滤后的结果，完全符合你的SQL预期。

方案2：实体类加固定过滤注解（固定规则场景使用） #

如果你的业务中所有加载TableA关联TableB的场景，都需要固定带上某个过滤条件，可以直接在@OneToMany字段上加Hibernate的@Where注解，加载关联集合时自动拼接过滤条件：

@OneToMany
@JoinColumn(name="roleNo")
@Where(clause = "activityId = 3") // 括号内写表字段对应的SQL过滤片段
private List<TableB> tableb;

注意：该方案是全局生效的，所有加载该关联集合的场景都会自动带上这个过滤条件，不支持动态传参，你的场景需要动态传入activityId值，优先选择方案1。 #

避坑提醒 #

不要尝试通过把@OneToMany的抓取策略改成FetchType.EAGER解决问题，该修改只会强制提前加载关联集合，依然会触发不带过滤条件的第二条SQL，无法解决过滤逻辑缺失的问题，还会导致所有查询TableA的场景都强制加载关联数据，带来不必要的性能损耗。

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