A web app loads a list of 50 orders, then in a template loop calls order.getLineItems() for each one, and the ORM fires 50 separate SELECT statements plus the original query. What is this problem called, why does lazy loading cause it, and how would you fix it without simply switching every association to eager loading?

## Where the name comes from The N+1 selects problem gets its name from the query count: one query retrieves the N parent rows (here, 50 orders), and then, because the association from order to its line items is lazily loaded, each of the N orders triggers its own additional query to fetch its line items when the code accesses that association - N extra queries, for a total of N+1 round trips to the database. In the scenario described, that's 51 SQL statements to render one page, where a well-designed query could have done the same job in one or two. ## Why lazy loading produces it This happens because of how Lazy Load works: rather than fetching an entire object graph eagerly at load time (which would be wasteful if most code paths never touch the association), the ORM defers fetching an association until the moment application code actually accesses it - typically via a lazy-loading proxy or collection wrapper. That deferral is a **deliberate, usually beneficial design choice**: most queries against an Order don't need its line items, and eagerly joining them on every load would waste bandwidth and rows. The problem isn't that lazy loading exists - it's that a loop which touches the lazy association once per parent, with no awareness that it's about to do this 50 times, ends up issuing the fetch 50 separate times instead of once, because each access is evaluated independently with no batching context connecting it to the other 49. ## Why making everything eager is a bad trade The naive 'fix' of switching the line-items association to eager loading globally trades one problem for another: every single query that loads an Order - even ones that only need the order's total and status for a summary list - now also joins or separately fetches all of its line items, whether needed or not. On a hot path that lists thousands of orders without ever showing their line items, this is strictly worse: - more data moved over the wire, - more rows joined, - and (if done via a `SQL JOIN` across a one-to-many) a multiplied result set that then has to be deduplicated in application code. The trade-off is fundamentally per use case, not per mapping: the same association should sometimes be lazy and sometimes eager depending on what a specific screen or endpoint actually needs, which argues for controlling fetch strategy at the query level rather than baking one choice permanently into the mapping. ## The standard fixes The standard fixes, roughly in order of how surgical they are: - **(1) A fetch join scoped to one query** - e.g. a JPQL/HQL query with `JOIN FETCH`, or an explicit eager-fetch hint - that eagerly pulls line items only for that specific query, leaving every other load of Order untouched. - **(2) Batch fetching / subselect fetching**, where the ORM (Hibernate's `@BatchSize` or subselect fetch mode is a well-known example) still defers the fetch but, on the first access, loads line items for all orders already in the current result set with one `IN (...)` query instead of one query per order, cutting N+1 down to roughly 2 total queries. - **(3) A purpose-built projection or DTO query** that selects only the columns the screen actually renders, bypassing the full entity graph and its lazy proxies entirely, which is usually the best choice for read-heavy, high-traffic list views. Which of these to reach for depends on whether the full domain objects are still needed downstream (favoring a fetch join or batch fetch) or whether the endpoint is a pure read view (favoring a DTO projection). ## How it shows up in production In production, N+1 shows up as a page or API endpoint that is mysteriously slow under realistic data volumes despite looking fine with a handful of test rows, and it's usually diagnosed by turning on SQL statement logging (or a tool like Hibernate's statistics, or an APM's query-count-per-request metric) and noticing the query count scales linearly with the number of rows on the page rather than staying constant. It's one of the most common production performance bugs in ORM-based systems precisely because it's invisible in development with tiny datasets and only bites once a list grows to dozens or hundreds of rows - a report or dashboard endpoint that joins several such lazy associations can turn what should be a two-query page load into hundreds of round trips, each carrying real network latency.