0Pricing
MongoDB Academy · 강의

복합 인덱스 접두사 규칙과 ESR 원칙

학습자는 최대한의 쿼리 범위를 확보하기 위해 복합 인덱스에 동등성-정렬-범위 인덱스 설계 원칙을 적용합니다.

복합 인덱스 접두사 규칙과 ESR 원칙은(는) CoddyKit의 무료 MongoDB Academy 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 MongoDB Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. MongoDB Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Compound Index Field Order Matters

A compound index on multiple fields can serve a wide range of queries — but only if the fields appear in the right order. MongoDB can use a compound index to satisfy a query only if the query's filter matches a prefix of the index. The ordering of fields in the index definition directly controls which queries benefit from it.

The Prefix Rule Explained

A compound index { a: 1, b: 1, c: 1 } can be used by queries that filter on: { a }, { a, b }, or { a, b, c }. These are the prefixes. A query filtering only on { b } or { b, c } cannot use this index — it would do a collection scan. The index is like a phone book sorted by last name, then first name: you can look up by last name alone or by last + first, but not by first name alone.

// Index: { status: 1, customerId: 1, createdAt: 1 }
db.orders.createIndex({ status: 1, customerId: 1, createdAt: 1 })

// Uses index (prefix: status)
db.orders.find({ status: 'pending' })

// Uses index (prefix: status + customerId)
db.orders.find({ status: 'pending', customerId: 'c001' })

// Does NOT use index (no leading prefix)
db.orders.find({ customerId: 'c001' })

The ESR Principle: Equality, Sort, Range

The ESR principle is a field-ordering rule for compound indexes: put Equality fields first, Sort fields second, and Range fields last. This ordering maximises the portion of the query the index can satisfy and minimises the number of index entries that must be examined. ESR is the most important compound index design rule in MongoDB.

// Query: find pending orders for customer c001, sorted by date,
// for dates after Jan 2025
// E: status = 'pending' (equality)
// S: createdAt (sort)
// R: customerId in ['c001','c002'] (range / $in)

// ESR-ordered index
db.orders.createIndex({ status: 1, createdAt: 1, customerId: 1 })

Why Equality Fields Come First

Equality predicates (field: value or $eq) narrow the index scan to a single, fixed value. Placing them first dramatically reduces the number of index entries the query planner needs to consider. Once equality has pinpointed the exact bucket of matching keys, the sort and range operations work on a much smaller dataset.

// E first: status equality narrows to ~5% of index
// Then sort on createdAt within that slice
// Then range on amount within that sorted slice
db.orders.createIndex({ status: 1, createdAt: 1, amount: 1 })

db.orders.find({ status: 'shipped' })
  .sort({ createdAt: -1 })
  .hint({ status: 1, createdAt: 1, amount: 1 })

Why Sort Fields Come Before Range

Placing sort fields before range fields allows MongoDB to use the index to satisfy the sort without a blocking in-memory sort. If range fields come before sort fields, MongoDB must scan all matching range documents, sort them in memory, then return results — adding CPU and memory overhead. With sort fields second, results emerge from the index already in the correct order.

// Without ESR: range before sort forces in-memory sort
db.orders.createIndex({ status: 1, amount: 1, createdAt: 1 })

db.orders.find({ status: 'pending', amount: { $gt: 50 } })
  .sort({ createdAt: 1 })
// explain() shows: SORT stage (in-memory sort needed)

// With ESR: sort before range avoids in-memory sort
db.orders.createIndex({ status: 1, createdAt: 1, amount: 1 })
// explain() shows: no SORT stage

Range Fields Last: Why It Works

Range predicates like $gt, $lt, $gte, $lte, $in, and regex span a contiguous portion of the index. By placing them last, MongoDB first narrows results with equality and delivers them in sort order, then applies the range check as a final filter. The index scan stays efficient because range does not break the sorted traversal order set by the sort fields.

// ESR applied correctly
// E: userId (equality)
// S: timestamp (sort)
// R: score (range)
db.events.createIndex({ userId: 1, timestamp: 1, score: 1 })

db.events.find({
  userId: 'u123',
  score: { $gte: 80 }
}).sort({ timestamp: -1 })

Handling $in: Range or Equality?

$in with a small list of values behaves more like equality and can be placed first. When the list is large, it acts more like a range and should go later in the index. A useful rule: if the $in list has fewer than 10–20 values and you query it frequently, treat it as equality (first). For large, dynamic lists, treat it as range (last).

// Small $in (2 values) — treat as equality, put first
db.orders.createIndex({ status: 1, createdAt: 1 })
db.orders.find({ status: { $in: ['pending', 'processing'] } })
  .sort({ createdAt: -1 })

// Large $in — treat as range, put last
db.orders.createIndex({ region: 1, createdAt: 1, userId: 1 })
db.orders.find({
  region: 'EU',
  userId: { $in: hundredsOfUserIds }
}).sort({ createdAt: -1 })

Verifying ESR With explain()

Always verify your index design with explain('executionStats'). Look for: IXSCAN (index scan) — good. COLLSCAN (collection scan) — missing index. SORT stage present — in-memory sort, index field order might be wrong. keysExamined / nReturned should be close to 1 for an optimal compound index.

db.orders.find({ status: 'pending', amount: { $gt: 50 } })
  .sort({ createdAt: 1 })
  .explain('executionStats')

// Good: { stage: 'IXSCAN', nReturned: 42, keysExamined: 44 }
// Bad:  { stage: 'COLLSCAN', nReturned: 42, docsExamined: 500000 }

The Prefix Rule and Partial Index Reuse

Thanks to the prefix rule, a single well-designed compound index can replace several single-field indexes. An index on { a: 1, b: 1, c: 1 } makes separate indexes on { a: 1 } and { a: 1, b: 1 } redundant. Fewer indexes means less write overhead and less memory pressure — important for write-heavy workloads where index maintenance adds latency to every insert, update, and delete.

// One compound index replaces three single-field indexes
db.users.createIndex({ country: 1, city: 1, age: 1 })

// Redundant (covered by compound prefix rule):
// db.users.createIndex({ country: 1 })          -- REDUNDANT
// db.users.createIndex({ country: 1, city: 1 }) -- REDUNDANT

Index Selectivity and Field Order

Beyond ESR, consider selectivity — how many documents share the same value. Put the most selective equality field first (fewest duplicates). For example, userId is more selective than status. Placing the more selective field first narrows the scan faster. When multiple equality fields exist, order them most-selective to least-selective for maximum performance.

// userId is highly selective (millions of users)
// status is low-selectivity (only 5 values)

// More efficient: selective equality field first
db.orders.createIndex({ userId: 1, status: 1, createdAt: 1 })

// Less efficient: low-selectivity field first
db.orders.createIndex({ status: 1, userId: 1, createdAt: 1 })

Putting ESR Into Practice

When designing a compound index, start by listing your top query's filter conditions and sort, then classify each field as E (equality), S (sort), or R (range). Build the index in that order. Run explain('executionStats') to confirm you see an IXSCAN with no SORT stage and a keysExamined/nReturned ratio near 1. Revisit the index whenever query patterns change.

// Practical checklist:
// Query: find users in 'NY' (E), sorted by signup (S), age > 18 (R)
// E: state = 'NY'
// S: signupDate
// R: age > 18
db.users.createIndex({ state: 1, signupDate: 1, age: 1 })

// Verify no in-memory sort and good key ratio:
db.users.find({ state: 'NY', age: { $gt: 18 } })
  .sort({ signupDate: -1 })
  .explain('executionStats')

Quick Check

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

Lesson Recap

In this lesson you learned: a compound index can only be used when the query matches a prefix of the index fields, the ESR principle dictates ordering fields as Equality, Sort, Range for maximum query coverage, and placing sort fields before range fields eliminates costly in-memory sort stages. Next up we compare index intersection versus compound indexes.

자주 묻는 질문

“복합 인덱스 접두사 규칙과 ESR 원칙” 강의는 무료인가요?

네 — “복합 인덱스 접두사 규칙과 ESR 원칙” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 MongoDB Academy 강의 전체를 잠금 해제할 수 있습니다. MongoDB Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“복합 인덱스 접두사 규칙과 ESR 원칙”에서 뭘 배우나요?

학습자는 최대한의 쿼리 범위를 확보하기 위해 복합 인덱스에 동등성-정렬-범위 인덱스 설계 원칙을 적용합니다. 브라우저에서 직접 실행하는 실습 코드로 MongoDB Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

MongoDB Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 MongoDB Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“복합 인덱스 접두사 규칙과 ESR 원칙” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 MongoDB Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 MongoDB Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 데이터베이스 프로파일러와 느린 쿼리 로그
  2. 복합 인덱스 접두사 규칙과 ESR 원칙
  3. 인덱스 교차와 복합 인덱스 비교
  4. 집계 파이프라인 최적화 팁
← MongoDB Academy(으)로 돌아가기