如何通过Spring-Data-JPA获取a_Id、b_id、c_Id的映射对象？

嘿，我完全懂你的痛点——不想触发N+1查询，又不愿改FetchType.EAGER，还要拿到清晰的ID映射对象。给你几个实用的方案，都是一次查询搞定：

方案1：接口投影（最简洁，无需额外DTO类） #

先定义一个投影接口，只暴露你需要的ID字段：

public interface IdMappingProjection {
    Long getAId();
    Long getBId();
    Long getCId();
}

然后在你的ARepository里添加查询方法，Spring Data JPA会自动生成只查所需字段的SQL，一次性关联获取B和C的ID：

public interface ARepository extends JpaRepository<A, Long> {
    // 派生查询自动投影，无需写SQL
    List<IdMappingProjection> findAllProjectedBy();

    // 或者用JPQL明确指定字段，更可控
    @Query("SELECT a.aId as aId, a.b.bId as bId, a.c.cId as cId FROM A a")
    List<IdMappingProjection> findAllIdMappings();
}

这个方案零冗余代码，Spring会自动处理关联字段查询，只返回三个ID，不会加载多余属性，也不会触发懒加载。

方案2：构造函数投影（类型安全，适合复杂场景） #

先创建一个简单的DTO类，带对应的构造函数：

public class IdMappingDTO {
    private final Long aId;
    private final Long bId;
    private final Long cId;

    public IdMappingDTO(Long aId, Long bId, Long cId) {
        this.aId = aId;
        this.bId = bId;
        this.cId = cId;
    }

    // getter方法
    public Long getAId() { return aId; }
    public Long getBId() { return bId; }
    public Long getCId() { return cId; }
}

然后在Repository里用JPQL直接构造这个DTO：

public interface ARepository extends JpaRepository<A, Long> {
    @Query("SELECT new com.yourpackage.IdMappingDTO(a.aId, b.bId, c.cId) FROM A a " +
           "JOIN a.b b JOIN a.c c")
    List<IdMappingDTO> findAllIdMappings();
}

这个方案类型安全，编译器会检查构造函数参数匹配，查询逻辑也非常清晰。

方案3：原生SQL查询（适合自定义复杂SQL） #

如果需要完全控制SQL逻辑，比如复杂过滤、分组，可以用原生查询：

// 先调整DTO，添加默认构造函数和setter
public class IdMappingDTO {
    private Long aId;
    private Long bId;
    private Long cId;

    public IdMappingDTO() {}

    // setter和getter方法...
}

// Repository里的方法
public interface ARepository extends JpaRepository<A, Long> {
    @Query(value = "SELECT a.a_id AS aId, b.b_id AS bId, c.c_id AS cId " +
                   "FROM A a JOIN B b ON a.b_id = b.b_id " +
                   "JOIN C c ON a.c_id = c.c_id",
           nativeQuery = true)
    List<IdMappingDTO> findAllIdMappings();
}

只要DTO字段名和查询结果别名一致，Spring会自动完成映射，适合需要自定义SQL的场景。

核心优势：为什么这些方案不会触发N+1？ #

所有方案都是一次查询获取所有需要的ID，要么通过JPQL关联查询，要么通过原生SQL join，不会加载完整的A、B、C实体，更不会触发懒加载的额外查询——我们只查询了三个ID字段，没有加载实体的其他属性和关联对象。

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