What is the N+1 select problem, and how do you solve it in Spring Data JPA?

The N+1 select problem is one of the most common Spring Data JPA performance pitfalls: fetching a list of N parent entities executes 1 query for the parents, and then, if code subsequently accesses a lazily-loaded association on each one, triggers N additional queries — one per parent — to fetch each one's related data separately, instead of retrieving everything in a single, efficient join.

List<Order> orders = orderRepository.findAll(); // 1 query
for (Order order : orders) {
    System.out.println(order.getCustomer().getName()); // triggers 1 lazy-load query PER order — N+1 total!
}

For 100 orders, that's 101 round trips to the database instead of one well-formed join — a significant, often silent performance problem that gets worse linearly as data grows.

Solutions:

1. JOIN FETCH in a JPQL query — explicitly eager-fetches the association in the same query, for that specific query only (doesn't change the entity's default fetch behavior elsewhere):

@Query("SELECT o FROM Order o JOIN FETCH o.customer WHERE o.status = :status")
List<Order> findByStatusWithCustomer(@Param("status") String status);

2. @EntityGraph — declaratively specifies which associations to eagerly fetch for a given repository method, without hand-writing JPQL:

@EntityGraph(attributePaths = {"customer", "lineItems"})
List<Order> findByStatus(String status);

3. Changing the association's default fetch type (a blunter, less flexible fix) — switching @ManyToOne/@OneToOne to FetchType.LAZY explicitly (they default to EAGER, ironically the opposite direction from the N+1 concern for those specific association types) or reconsidering whether an association should be eager at all — but a blanket EAGER setting risks over-fetching data that most queries don't actually need, so targeted per-query solutions (JOIN FETCH/@EntityGraph) are usually preferable to a blanket entity-level change.

Detecting the problem in the first place: enabling Hibernate's SQL logging (spring.jpa.show-sql=true, or better, a proper SQL statement counter/logging tool in tests) during development is essential — the N+1 problem is easy to miss entirely in casual manual testing with small datasets, since the extra queries are individually fast; it only becomes visibly painful at production scale.