Why it is invisible in the code
List<Order> orders = orderRepository.findByCustomerId(id, PageRequest.of(0, 50));
return orders;
Reading this method will never reveal the problem, because the N queries are emitted by code nobody wrote: Jackson calls order.getLines(), Hibernate sees an uninitialised proxy, and it issues SELECT * FROM order_line WHERE order_id = ? — once per order. Fifty orders become fifty-one statements. Add a lazy customer on each line and it is worse.
The reason this fails silently rather than loudly is spring.jpa.open-in-view, which defaults to true. It holds the EntityManager open for the whole request, so lazy loads outside the service layer work. Turn it off and the same code throws LazyInitializationException at serialisation time — noisy, but honest. Spring Boot logs a warning about this default at startup precisely because it converts a visible error into an invisible performance problem.
Diagnose by counting, not by reading
The reliable move is to measure statements per request. Reading code for N+1 does not scale and misses the cases where the association is touched three layers away.
spring.jpa.properties.hibernate.generate_statistics=true
logging.level.org.hibernate.stat=DEBUG
# and, to see the actual SQL with bound parameters, a proxy such as
# datasource-proxy or p6spy - not show-sql, which omits the bindings
Hit the endpoint once and read the statement count off the statistics line. If fifty orders produce fifty-one queries, you have found it without guessing. This also gives you the number to put in a regression test later, which matters because N+1 reappears the moment someone adds a field to a DTO.
Fixing one collection: join fetch or entity graph
For a single association, fetch it in the same statement:
@Query("select distinct o from Order o join fetch o.lines where o.customerId = :id")
List<Order> findWithLines(@Param("id") Long id);
or declaratively, which keeps the derived query and is usually the better default in Spring Data:
@EntityGraph(attributePaths = {"lines"})
List<Order> findByCustomerId(Long id);
Both turn N+1 into one query. @EntityGraph is preferable when you want the repository's derived method or its pagination behaviour; a hand-written JPQL query is preferable when the fetch plan and the filtering need to be reasoned about together.
This is where the naive fix causes a worse problem, and interviewers ask about it because the symptom is confusing. Join-fetching a collection multiplies rows — fifty orders with ten lines each return five hundred rows — so the database can no longer apply LIMIT to give you fifty orders. Hibernate resolves this by fetching every matching row and paginating in memory, warning:
HHH000104: firstResult/maxResults specified with collection fetch; applying in memory
Your page size is now decoration. On a large result set the heap goes with it. The correct pattern is to page the ids first and fetch the collections for that page in a second query, or to switch to batch fetching, which paginates correctly by construction.
Stacking two collection join fetches fails differently and immediately, with MultipleBagFetchException: cannot simultaneously fetch multiple bags — Hibernate refusing to produce the cartesian product of two collections.
Fixing several collections: batch fetching
When more than one association is involved, batch fetching is the tool that scales. Instead of one query per parent, Hibernate collects uninitialised proxies and loads them in batches with an IN clause:
spring.jpa.properties.hibernate.default_batch_fetch_size=50
Fifty orders now cost two queries rather than fifty-one — one for the orders, one for all their lines. It does not multiply rows, so pagination keeps working, and it applies globally rather than requiring every query to be annotated. For most applications, setting a sane default batch fetch size is the single highest-value change, because it fixes the N+1s nobody has found yet.
Often the real answer: stop fetching entities
If the endpoint returns a fixed JSON shape, it probably never needed managed entities. A projection selects exactly the columns the response contains, in one query, with no persistence context, no proxies, and no possibility of N+1:
public interface OrderSummary {
Long getId();
String getStatus();
BigDecimal getTotal();
}
List<OrderSummary> findByCustomerId(Long id);
This is worth proposing explicitly, because a large share of N+1 problems are really a design mismatch — using the write model to serve a read endpoint. It also removes the open-session-in-view dependency for that path entirely.
What not to reach for
Changing the association to FetchType.EAGER looks like a fix and is a trap. It does eliminate the lazy load on this endpoint, at the cost of loading that collection on every query that touches the entity, including the ones that only needed the id. It converts a local problem into a global one, and it cannot be turned off per query. Fetch strategy belongs to the query, not to the mapping.
Keeping it fixed
Because N+1 regressions are silent, the durable answer includes a guard. Assert the statement count in an integration test — via Hibernate's Statistics.getPrepareStatementCount() or a datasource proxy — so that a future change which adds a lazy field to the response fails the build rather than quietly adding four hundred queries. Proposing that guard, rather than only the fix, is usually what separates a candidate who has debugged this once from one who has had to stop it coming back.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).