A service loads 200 order rows and then reads each order's customer name, and the database log shows 201 statements. Explain what is happening, why it is called the N+1 problem, and why it hurts more than the statement count suggests.

## The shape of the problem N+1 is the situation where retrieving a collection of N objects plus one related piece of data for each of them costs **N + 1** database statements instead of one or two. The canonical form: ```java List<Order> orders = em.createQuery("select o from Order o", Order.class) .getResultList(); // statement 1 for (Order o : orders) { print(o.getCustomer().getName()); // statements 2 .. N+1 } ``` The first statement returns the orders. Each `getCustomer()` returns an uninitialised proxy holding only the customer id; calling `getName()` forces the ORM to load that row, so it emits `select ... from customer where id = ?`. Two hundred orders, two hundred extra selects. The same shape appears with collections: ```java for (Order o : orders) { total += o.getLines().size(); // one SELECT per order } ``` ## Why it is invisible in the usual places Each individual statement is a primary-key lookup returning one row. It runs in microseconds, uses an index perfectly, and never crosses a slow-query threshold. The database's CPU graph is flat. Query plans are optimal. Everything the DBA looks at says the system is healthy. The damage lives on the **application side**, in the count of round trips. Every statement costs: - serialisation of the statement and parameters, - a network hop to the database and back, - connection/statement handling in the driver and pool, - ORM work to build the result and register the entity in the persistence context. At 0.5 ms of round-trip latency — a normal number for a database in the same datacentre — 200 statements is ~100 ms. Over a network link with 2 ms latency, it is 400 ms. A single join returning the same data is one round trip. ## Why it scales the wrong way N is the size of the result set, so cost grows linearly with data volume and with page size. It is the classic "worked in dev, died in prod" defect: the dev database has 20 orders and the production one has 20,000. It also compounds under concurrency — each request holds its connection for the whole burst of statements, so pool exhaustion arrives well before the database is actually busy. Two N+1s nested inside each other (parents, then children, then grandchildren) multiply. ## Where the extra statements come from There are two distinct origins worth naming: 1. **Lazy associations dereferenced in a loop** — the example above. The mapping is correct; the *query* did not fetch what the code went on to use. 2. **Eagerly-mapped to-one associations in a query result** — the ORM must satisfy the eager contract, and for a JPQL/HQL result list it typically does so with a secondary select per row rather than by rewriting your query into a join. Here the loop is not even necessary; simply returning the list triggers it. Both are the same defect from the database's point of view: the fetch plan for this use case was never expressed. ## What partially masks it - **Repeated parents.** If 200 orders belong to 5 customers, only 5 selects run — the persistence context returns the already-loaded instance for the rest. So the observed count depends on data distribution, and a test fixture with one shared customer hides the problem completely. - **Caching.** A second-level cache hit avoids the statement entirely, so an N+1 can be invisible on a warm system and brutal after a deploy. ## How it is fixed, in outline The correct fix is to declare the data the use case needs at query time — a fetch join or an entity graph — or to project only the columns you need into a DTO so associations never enter the picture. Batching strategies reduce N+1 to N/batch + 1 without changing the query. What all of these have in common is that the *query*, not the mapping, expresses the use case. ## The one-sentence version "One query for the parents, then one more per parent because the data the loop needed was not in the original fetch — cheap statements, expensive round trips, and it gets worse as the table grows."