Indexing for the Data Model
What this domain tests
Indexing for the Data Model tests whether your indexes follow the queries your model serves. Expect compound index order, the ESR rule, multikey indexes, covered queries, selectivity, TTL indexes, and unique indexes.
Core rules
- Build indexes from query shapes, not from every field.
- Use the ESR rule for compound indexes: Equality fields first, then Sort fields, then Range fields.
- A compound index can serve queries that use a prefix of its fields.
- A multikey index is created when an indexed field is an array; each array element becomes an index entry.
- A covered query returns results from the index alone when all queried and projected fields are in the index and no field is multikey in a way that prevents it.
- TTL indexes delete documents after a date field plus
expireAfterSeconds. - Unique indexes enforce uniqueness, including on compound keys.
- Over-indexing slows writes and consumes memory.
Worked example
Query: {region:'EU', status:'shipped', total:{$gt:100}}, sort {createdAt:-1}. Build {region:1, status:1, createdAt:-1, total:1}. region and status are equality fields, createdAt is the sort field, and total is the range field. Putting total before the sort would force an in-memory sort. A separate index on status alone is redundant only if queries always include region; because the compound index's prefix is region, a query on status alone needs an index starting with status.
Traps
Ordering a range field before a sort field; creating one index per field; ignoring multikey restrictions; using low-selectivity indexes alone; and indexing fields that are never queried.