3) How MongoDB Executes a Query

3) Using explain() to Diagnose Bottlenecks

4) Index Types and When to Use Them

• Compound Indexes
• Multikey Indexes
• Text Indexes

5) Measuring Index Efficiency

6) Winning Plans and the Plan Cache

Why Collection Scans Kill Performance

To understand why indexing matters, it helps to see what happens when it is absent. Without an index, MongoDB scans the entire collection, checking each document one by one to find matches. As collections grow larger, this process becomes slower because the database must read more data, increasing CPU usage, disk activity, and query time.

Indexes prevent this by giving MongoDB a structured way to locate data. They use tree based structures that allow the engine to jump directly to relevant documents, avoiding a full scan and keeping performance stable even as data volume grows.

// Creating a basic index on the "email" field
  db.users.createIndex({ email: 1 }); // 1 = ascending, -1 = descending

How MongoDB Executes a Query

When a query reaches MongoDB, it goes through a multi-stage execution pipeline.

1. Query Arrival- The query is received by the mongod process.
2. Index Discovery- The Query Planner checks which indexes are available for the queried fields.
3. Candidate Plan Generation- If multiple indexes could satisfy the query, MongoDB generates multiple query plans.
4. Plan Ranking- MongoDB may execute these plans in parallel for a short time to measure performance.
5. Index Scan (IXSCAN)- The selected plan traverses the B-Tree to locate matching document pointers.
6. Document Fetch (FETCH)- MongoDB retrieves the actual documents using disk locators from the index.

The goal is always to replace COLLSCAN with IXSCAN.

Using explain() to Diagnose Bottlenecks

As database systems grow, performance shifts from a convenience to a core requirement. When MongoDB collections expand from a few hundred documents to millions, query efficiency becomes the key factor that determines scalability. Without proper indexing, MongoDB is forced to scan large portions of data, similar to reading an entire book to find a single sentence. This article explains how MongoDB executes queries internally, how tools like explain() help uncover performance bottlenecks, and how well-designed indexes ensure consistently fast and reliable query responses at scale.

Critical Fields to Watch

winningPlan.stage

• IXSCAN is desired; COLLSCAN indicates missing indexes.

executionStats.nReturned

• Number of documents matched.

executionStats.totalKeysExamined

• Number of index entries scanned.

executionStats.totalDocsExamined

• Number of documents read from disk.

Index Types and When to Use Them

MongoDB provides several specialized index types to handle complex data structures.

Compound Indexes

Compound indexes in MongoDB span multiple fields, and their order directly impacts performance. An index like { status: 1, date: -1 } efficiently filters by status while sorting by the newest date. A common best practice is the ESR rule: place equality fields first, sort fields next, and range fields last.

Multikey Indexes

When an indexed field contains an array, MongoDB automatically creates a multikey index. Each array element becomes its own index entry.

This allows efficient querying inside arrays without scanning full documents.

Text Indexes

Text indexes support keyword-based searches rather than exact matches. They tokenize and stem string data for full-text search capabilities.

db.articles.createIndex({ content: "text" });

Measuring Index Efficiency

A good index is not just about existence, but about selectivity. Efficient queries examine roughly the same number of index keys and documents as the results they return; large gaps between these numbers signal poor index design. When totalDocsExamined is zero and results are still returned, the query is covered. Covered queries are especially fast because MongoDB can satisfy them entirely from the index without reading documents from disk.

Winning Plans and the Plan Cache

To avoid repeatedly comparing expensive query plans, MongoDB maintains a Plan Cache. Once the query planner identifies the most efficient execution plan for a given query shape, meaning the same fields with different values, it stores that plan in memory. Subsequent queries can then skip the planning phase and execute immediately. The plan cache is invalidated when indexes are added or rebuilt, the mongod process restarts, or significant changes occur in data distribution.

Final Thoughts and Next Steps

High-performance MongoDB systems are built through intentional indexing, not by adding indexes indiscriminately. Collection scans steadily degrade performance, while well-designed indexes enable predictable and scalable query execution. A strong optimization workflow should include query profiling, regular explain() analysis, and slow-query logging (with the default 100 ms threshold). Keep in mind that every index adds write overhead, over-indexing can slow inserts and updates. Effective indexing is therefore an iterative process of measuring, refining, and validating.

Reference

• MongoDB Documentation: Query Optimization and Indexing
• ESR Rule: Equality, Sort, Range
• WiredTiger Storage Engine and Index Interaction