0Pricing
MongoDB Academy · Lekcja

Przecinanie indeksów a indeksy złożone

Nauczą się Państwo rozumieć, kiedy MongoDB przecina wiele indeksów jednopolowych, a kiedy indeks złożony zapewnia lepszą wydajność niż takie przecinanie.

Przecinanie indeksów a indeksy złożone to bezpłatna lekcja MongoDB Academy na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej MongoDB Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs MongoDB Academy zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

What Is Index Intersection?

Index intersection is MongoDB's ability to use two or more single-field indexes simultaneously to satisfy a single query. Instead of building one compound index that covers all filter fields, MongoDB scans multiple indexes independently, then takes the intersection of their matching document IDs. It sounds convenient, but in practice it is rarely as fast as a well-designed compound index.

How Index Intersection Works Internally

When MongoDB considers intersecting indexes, the query planner: 1) Scans index A for documents matching condition 1 and collects their record IDs. 2) Scans index B for documents matching condition 2. 3) Computes the intersection of the two ID sets. 4) Fetches the actual documents using those IDs. This is called an AND_SORTED or AND_HASH stage in explain() output.

// With two single-field indexes:
db.orders.createIndex({ status: 1 })
db.orders.createIndex({ customerId: 1 })

// Query may intersect both indexes
db.orders.find({ status: 'pending', customerId: 'c001' })
  .explain('executionStats')
// Look for 'AND_SORTED' or 'AND_HASH' stage in winningPlan

When MongoDB Chooses Intersection

MongoDB uses index intersection only when its query planner calculates that it is cheaper than alternatives. The planner runs up to 200 candidate plans in parallel (using trial execution) and picks the one with the lowest estimated cost. Intersection is more likely to be chosen when the collection is large and each individual index is highly selective — both narrow the candidate set dramatically before the intersection step.

// Check if MongoDB chose to intersect indexes
const plan = db.orders.find({
  status: 'pending',
  customerId: 'c001'
}).explain('executionStats')

// Intersection chosen:
print(JSON.stringify(plan.queryPlanner.winningPlan, null, 2))
// Look for: 'stage': 'AND_SORTED'

Compound Index vs Intersection: Key Difference

A compound index stores keys from multiple fields in a single, pre-sorted B-tree. A query on those fields does a single, efficient index scan and returns documents in sorted order. Index intersection does multiple separate scans and then merges the results in memory. The merge step adds CPU and memory overhead that a compound index avoids entirely.

// Compound index: one scan, sorted output
db.orders.createIndex({ status: 1, customerId: 1 })

// Single scan: fast, no in-memory merge
db.orders.find({ status: 'pending', customerId: 'c001' })
// explain(): IXSCAN stage only — no AND_SORTED

Compound Indexes Win on Sort

Index intersection cannot satisfy a sort — the merged result set is not in any particular order relative to the sort key, so MongoDB must perform an in-memory SORT stage. A compound index that includes the sort field delivers results in order directly from the index, avoiding the sort overhead entirely. For queries that both filter and sort, a compound index almost always wins.

// Index intersection + sort = in-memory sort required
db.orders.find({ status: 'pending', customerId: 'c001' })
  .sort({ createdAt: 1 })
// Even if both status and customerId indexes intersect,
// MongoDB must still sort the merged result in memory

// Compound index avoids the sort stage
db.orders.createIndex({ status: 1, customerId: 1, createdAt: 1 })

When Intersection Can Outperform Compound

Index intersection occasionally beats a compound index when: 1) Both individual indexes are highly selective (each returns very few documents). 2) The query is ad-hoc — you cannot predict which fields will be filtered together so building a compound index for every combination is impractical. 3) The collection is write-heavy — fewer indexes means lower write overhead, so using intersection from two existing indexes avoids adding a third.

Controlling the Query Planner With hint()

You can force MongoDB to use a specific index (or intersection strategy) with .hint(). This bypasses the query planner's automatic selection and is useful for benchmarking — you can compare the execution stats of your manually chosen compound index versus what the planner would do with individual indexes.

// Force a specific compound index
db.orders.find({ status: 'pending', customerId: 'c001' })
  .hint({ status: 1, customerId: 1 })
  .explain('executionStats')

// Force use of a single-field index (no intersection)
db.orders.find({ status: 'pending', customerId: 'c001' })
  .hint({ status: 1 })
  .explain('executionStats')

Detecting Intersection in explain() Output

When MongoDB uses index intersection, the explain() output shows an AND_SORTED or AND_HASH stage as the parent of two IXSCAN stages. AND_SORTED is used when both indexes return results in the same sorted order; AND_HASH builds an in-memory hash of one result set and probes it with the other. Both are signs that a well-chosen compound index could be faster.

// Identify intersection usage
const plan = db.orders
  .find({ status: 'pending', region: 'EU' })
  .explain('executionStats')

// Check for AND_SORTED or AND_HASH
// If found, benchmark against a compound index { status:1, region:1 }

The General Rule: Prefer Compound Indexes

For known, repeated query patterns, a compound index is almost always faster than relying on intersection. The only reasons to prefer intersection are: queries are too unpredictable to cover with compound indexes, or write throughput is so high that adding more indexes is too costly. In those cases, keep individual indexes lean and let the planner intersect when it helps.

Index Audit: Removing Redundant Indexes

As applications evolve, developers add indexes reactively. Over time, collections accumulate redundant indexes that slow writes without benefiting reads. Review regularly using $indexStats: any index with zero accesses.ops over a long period is unused and can be dropped. Also look for indexes made redundant by the compound prefix rule.

// Identify unused indexes
db.orders.aggregate([{ $indexStats: {} }])
// { name: 'status_1', accesses: { ops: 0, since: ... } }
// If ops is 0 since a long time, the index is unused — drop it

db.orders.dropIndex('status_1')

Practical Guidance: A Decision Framework

Use this framework: Query pattern is known and repeated? → Build a compound index using ESR. Query is ad-hoc or hard to predict? → Rely on individual indexes and accept possible intersection. Write throughput is critical? → Minimise total index count; remove unused indexes. Query involves a sort? → Always use a compound index; intersection never satisfies sorts.

Quick Check

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

Lesson Recap

In this lesson you learned: index intersection uses two single-field indexes and merges their results in memory, adding overhead, compound indexes are almost always faster for known, repeated query patterns — especially those with sorts, and use $indexStats to find and remove unused or redundant indexes that slow writes. Next up we explore aggregation pipeline optimization tips.

Często zadawane pytania

Czy lekcja „Przecinanie indeksów a indeksy złożone” jest bezpłatna?

Tak — pełny tekst „Przecinanie indeksów a indeksy złożone” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu MongoDB Academy, przejdź na CoddyKit PRO. Kurs MongoDB Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Przecinanie indeksów a indeksy złożone”?

Nauczą się Państwo rozumieć, kiedy MongoDB przecina wiele indeksów jednopolowych, a kiedy indeks złożony zapewnia lepszą wydajność niż takie przecinanie. Ćwiczysz MongoDB Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć MongoDB Academy?

Nie wymagamy żadnego doświadczenia. MongoDB Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Przecinanie indeksów a indeksy złożone”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji MongoDB Academy?

Tak. Każda lekcja MongoDB Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Profiler bazy danych i dziennik wolnych zapytań
  2. Reguła prefiksu indeksu złożonego i zasada ESR
  3. Przecinanie indeksów a indeksy złożone
  4. Wskazówki dotyczące optymalizacji potoków agregacji
← Powrót do MongoDB Academy