为何JPA生成大量SELECT语句？附JPA与JdbcTemplate对比代码

嘿，这个问题我之前在项目里也踩过坑，其实核心原因是JPA的**懒加载（Lazy Loading）**机制在起作用，咱们来一步步理清楚：

为什么会生成大量额外的SELECT语句？ #

你的Products实体和Categories、Suppliers是@ManyToOne关联，而JPA中@ManyToOne的默认抓取策略是FetchType.LAZY（懒加载）。这意味着：

• 当你调用jpaProductRepository.findAll(...)时，JPA只会执行一次查询获取所有Products的基础数据，不会同时加载关联的Categories和Suppliers；
• 但之后只要你在代码中访问某个Products对象的categories或suppliers属性（比如前端渲染、日志打印、业务逻辑用到），JPA就会立刻触发单独的SELECT语句去数据库查询对应的关联实体。如果你的Product列表有N条数据，就会额外生成N次（甚至2N次）关联查询——这就是经典的N+1查询问题。

而你的JdbcTemplate实现没有这个问题，是因为你只执行了SELECT * FROM products，没有主动去关联查询Categories和Suppliers，也没有触发任何加载关联数据的逻辑，自然不会生成额外SQL。

你的代码有没有问题？ #

单从语法上来说，你的JPA代码没有错误，但如果你的业务场景中需要使用到关联的Categories或Suppliers数据，这种默认的懒加载会带来明显的性能损耗。我们可以通过以下几种方式优化：

方案1：使用实体图（EntityGraph）一次性加载关联实体 #

在你的JPA Repository接口中，定义带实体图的查询方法，明确指定要加载的关联属性：

@Repository
public interface JpaProductRepository extends JpaRepository<Products, Long> {
    @EntityGraph(attributePaths = {"categories", "suppliers"})
    List<Products> findAll(Sort sort);
}

这样JPA会自动生成包含JOIN的SQL，一次性把Products和关联的Categories、Suppliers数据全部查询出来，彻底避免N+1问题。

方案2：用JPQL手动写JOIN FETCH查询 #

如果你需要更灵活的查询逻辑，可以直接写JPQL语句，通过JOIN FETCH强制加载关联实体：

@Query("SELECT p FROM Products p JOIN FETCH p.categories JOIN FETCH p.suppliers ORDER BY p.productname ASC")
List<Products> listProductsSortedByProductName();

这种方式能精准控制要加载的关联对象，适合复杂查询场景。

方案3：修改关联的抓取策略为EAGER（不推荐） #

你可以把@ManyToOne的fetch属性改为FetchType.EAGER：

@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "category_id")
private Categories categories;

@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "supplier_id")
private Suppliers suppliers;

但这种方式不推荐，因为EAGER会强制JPA每次查询Products都加载关联实体，无论你是否需要，可能会导致不必要的性能开销，尤其是当关联实体本身还有其他关联的时候。

总结 #

问题的本质是JPA默认懒加载带来的N+1查询，你的代码本身没有错误，但可以根据业务需求选择上述优化方案来减少额外的SQL生成，提升查询性能。

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