Learn the vocabulary of one query turning into N extra queries inside a loop, and how batching fixes it.
0 / 5 completed
1 / 5
At standup, a dev mentions an ORM lazy-loading each order's line items one query at a time inside a loop, so listing 100 orders fires 101 separate queries instead of one. What is this pattern called?
The N+1 query problem is exactly this: one query to fetch the N orders, then one additional query per order to lazy-load its line items, for a total of N+1 round trips instead of a single join or batch fetch. Connection pooling only concerns reusing existing connections and says nothing about how many queries a page load issues. This pattern is one of the most common performance bugs introduced by an ORM's convenient lazy-loading default.
2 / 5
During a design review, the team wants all 100 orders and their line items fetched in a single query using a join or an explicit batch loader, instead of one query per order. Which capability supports this?
Eager loading, or a batching data loader, fetches all the related rows for every order in one round trip, typically via a join or a single WHERE IN query, instead of issuing a separate query per order. Continuing to lazy-load each order's line items individually is precisely the N+1 pattern the team is trying to eliminate. This batched fetching is what turns a linearly growing number of queries into a constant, small number regardless of how many orders are on the page.
3 / 5
In a code review, a dev notices a query-logging middleware reporting several hundred queries fired for a single page load that only displays 50 rows. What does this represent?
A likely N+1 query problem is exactly what several hundred queries for only 50 displayed rows suggests, since a well-batched page load should issue roughly a constant, small number of queries regardless of how many rows it renders. A cache hit ratio measures something else entirely and wouldn't explain a raw query count this high. This kind of query-count logging is a standard way to surface an N+1 bug that isn't obvious just from reading the code.
4 / 5
An incident report shows a product listing page started timing out once the catalog grew past a few thousand items, because each item's price lookup fired its own individual query inside a loop instead of one batched query. What practice would prevent this?
Batching the price lookups into a single query, such as a WHERE IN clause or a join, keeps the page issuing roughly the same number of queries regardless of how many items the catalog holds. Continuing to fire one query per item inside the loop is exactly what caused the timeout as the catalog grew past a few thousand items in this incident. This batching is the standard fix once an N+1 pattern has been identified as the source of a scaling problem.
5 / 5
During a PR review, a teammate asks why the team adds an explicit eager-load hint to a query instead of trusting the ORM's default lazy-loading behavior to fetch related data as it's needed. What is the reasoning?
Lazy loading fetches related data one row at a time as it's accessed, which turns into exactly one query per row once that access happens inside a loop over many parent rows. An explicit eager-load hint fetches all the related data in one batched query upfront, before the loop even starts, avoiding that per-row cost entirely. The tradeoff is that eager loading can over-fetch related data the loop never actually ends up needing, so it's best applied deliberately where the N+1 pattern is a known risk.
What does the "N+1 Query Problem Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to n+1 query problem vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.