What is the N+1 query problem, and how do you fix it?

Question

Accepted Answer

The N+1 problem is when you run one query to load a list of N items and then, for each item, run another query to load something related, so you end up issuing N+1 queries instead of a small constant number. It almost always comes from an ORM with lazy loading: you fetch a list of orders, then loop over them and access order.customer, and each access silently fires its own query to the database, which is invisible in the code because it just looks like a property access. The impact is brutal because each of those queries is a network round trip to the database, so 10 items means 11 queries, which is fine, but 10,000 items means 10,001 queries, which is why something that looks fast in development with a handful of rows falls over in production. The fix is to fetch the related data up front instead of per-row: eager-load the relationship, either with a JOIN or the ORM include or preload mechanism, so the related records come back with the original query, or batch the lookups, collect the IDs and do a single WHERE id IN (...) query. Either way you collapse N+1 into one or two queries. I catch these by watching query counts per request in APM or query logs, since the pattern hides in normal-looking ORM code.

Answer

Why does this often pass in development but fail in production?

In dev the lists are tiny (10 rows = 11 queries, fast). In prod the same code hits thousands of rows = thousands of round trips. The pattern scales with data volume, so it only hurts at real scale.

Answer

What is the difference between eager loading and batching here?

Eager loading fetches the relation along with the parent (a JOIN or ORM preload). Batching collects the IDs and issues a single IN query for all related rows. Both replace N per-row queries with one or two.

What is the N+1 query problem, and how do you fix it?

What is the N+1 query problem, and how do you fix it?

The follow-ups they ask next

What the interviewer is listening for

What sinks the answer

If you genuinely do not know

Keep going with databases

Knowing the answer is not the same as recalling it under pressure