MongoDB Covered Queries and the ESR Rule
Fast recall
Quick revision
Core answer
explain() plan shows IXSCAN → PROJECTION_COVERED with no `FETCH` stage. Achieving it requires a compound index that contains every field the query reads and excluding `_id` from projection unless it is in the index. The ESR rule (Equality → Sort → Range) drives field order: put exact-match predicates first, sort fields next, then range fields. Covered queries are the fastest possible read in MongoDB — they stay in RAM, never touch the document cache, and scale linearly with index size.Whether you understand the difference between index-hitting and covered queries and can design for the fastest read path
Thinking any IXSCAN is 'covered', or leaving `_id: 1` in projection and losing coverage
Walk through an `explain('executionStats')` output, show ESR-compliant index design, and name the FETCH-stage absence as the signal of coverage
Interview-ready guide
Interview answer
Define coverage
- Covered query: index alone answers filter + sort + projection
- Fastest possible read in MongoDB
Apply the ESR rule
- Equality predicates first, sort fields next, range fields last
- Include projected fields so no fetch is needed
- Drop
_idfrom projection unless it's in the index
Verify with explain
PROJECTION_COVEREDwrapsIXSCAN- No
FETCHstage totalDocsExamined: 0
Close with trade-offs
- Every covering index slows writes
- Multikey generally breaks coverage
- Use
$indexStatsto confirm traffic
MongoDB Covered Queries and the ESR Rule
Direct Answer
A covered query is served entirely from an index — filter, sort, and projection all hit index fields, so MongoDB never fetches the document body. The explain() plan shows IXSCAN → PROJECTION_COVERED with no FETCH stage. Achieving it requires a compound index that contains every field the query reads and excluding _id from projection unless it is in the index. The ESR rule (Equality → Sort → Range) drives field order: put exact-match predicates first, sort fields next, then range fields. Covered queries are the fastest possible read in MongoDB — they stay in RAM, never touch the document cache, and scale linearly with index size.
Common Mistakes & Pitfalls
Thinking any IXSCAN is 'covered', or leaving _id: 1 in projection and losing coverage
Check your understanding
Answer these without looking back at the article.
- Why does a multikey index usually prevent a covered query?
- How does `allowDiskUse()` affect sort execution when no covering index exists?
- What's the cost of adding a trailing field to a covering index just to cover a projection?
- When would you accept an uncovered query over the write cost of a wider index?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.