Choose the appropriate index type based on use case, such as single field, compound, multikey, text, geospatial, or TTL indexes. 2. Apply the ESR rule when creating compound indexes by ordering fields as equality, sort, then range. 3. Design indexes to support covered queries by including all query and projection fields, avoiding _id unless necessary. 4. Monitor index effectiveness using explain plans and $indexStats, remove unused or redundant indexes to reduce write overhead. 5. Use partial or sparse indexes to limit index size when indexing a subset of documents or fields that may be missing. 6. In sharded clusters, select a high-cardinality, evenly distributed shard key that aligns with common queries and minimize reliance on secondary indexes. Proper indexing in MongoDB requires aligning index strategy with query patterns, optimizing performance, and continuously evaluating usage to maintain efficiency.

When working with MongoDB, proper indexing is critical for performance—especially as your data grows. Without indexes, MongoDB must scan every document in a collection to find the ones matching a query (a collection scan), which becomes slow and resource-intensive. Here’s a practical guide to effective indexing strategies in MongoDB.

1. Choose the Right Index Type

MongoDB supports several index types, each suited for different use cases:

• Single Field Indexes: Best for queries filtering on one field.

  

  db.collection.createIndex({ "status": 1 })

• Compound Indexes: Ideal when queries involve multiple fields. Order matters—prefix fields used in equality checks first, then range or sort fields.

  db.collection.createIndex({ "status": 1, "createdAt": -1 })

• Multikey Indexes: Automatically created when indexing array fields. Useful for queries on array elements.

  

  db.collection.createIndex({ "tags": 1 })

• Text Indexes: Enable full-text search on string content.

  db.collection.createIndex({ "title": "text", "content": "text" })

• Geospatial Indexes: For location-based queries (2d, 2dsphere).

  db.collection.createIndex({ "location": "2dsphere" })

• TTL Indexes: Automatically expire data after a set time—great for logs or session data.

  db.collection.createIndex({ "createdAt": 1 }, { expireAfterSeconds: 3600 })

2. Follow the ESR (Equality, Sort, Range) Rule

When designing compound indexes, order fields based on how they’re used:

1. Equality – Fields with exact match conditions (status: "active")
2. Sort – Fields used in sorting (sort: { createdAt: -1 })
3. Range – Fields with range queries (createdAt > ...)

For example, this query:

db.orders.find(
  { status: "shipped", user: "jane" }
).sort({ createdAt: -1 })

Should use:

db.orders.createIndex({ status: 1, user: 1, createdAt: -1 })

This follows ESR: equality on status and user, then sort on createdAt.

3. Use Indexes for Projections and Covered Queries

A covered query is one where all requested fields are in the index, so MongoDB doesn’t need to fetch the full document. This can drastically improve performance.

Example:

db.users.createIndex({ "role": 1, "status": 1 })

This query can be covered:

db.users.find(
  { role: "admin" },
  { status: 1, _id: 0 }
)

Ensure the projection fields and query fields are all in the index, and avoid including _id unless indexed.

4. Monitor and Optimize Index Usage

Indexes aren’t free—they consume memory and slow down writes. Use these tools to manage them:

• Explain Plans: Use .explain("executionStats") to see if queries use indexes.

  db.collection.find({ status: "active" }).explain("executionStats")

  Look for IXSCAN (good) vs COLLSCAN (bad).

• Index Usage Stats: Check which indexes are actually used:

  db.collection.aggregate([{ $indexStats: {} }])

  If an index shows low or zero usage, consider dropping it.

• Avoid Redundant Indexes: Don’t create overlapping indexes. For example, if you have:

  { a: 1, b: 1 }

  You don’t need a separate { a: 1 } unless queries use only a and projection benefits.

5. Consider Partial and Sparse Indexes

• Partial Indexes: Index only a subset of documents that meet a filter condition. Saves space and improves performance.

  db.users.createIndex(
    { email: 1 },
    { partialFilterExpression: { email: { $exists: true } } }
  )

• Sparse Indexes: Only include documents with the indexed field. Useful when many documents lack the field.

  db.users.createIndex({ phone: 1 }, { sparse: true })

Note: Partial indexes are more flexible and often preferred over sparse indexes in modern MongoDB versions.

6. Plan for Sharded Clusters

In sharded environments, your shard key acts like a global index. Choose it carefully:

• High cardinality
• Even data distribution
• Supports common query patterns

Avoid monotonically increasing shard keys (like timestamps), which lead to "hot chunks" on one shard.

Also, secondary indexes in sharded clusters use a scatter-gather approach, which is slower. Use them sparingly and prefer queries that include the shard key.

Basically, indexing in MongoDB isn’t just about creating indexes—it’s about aligning them with your query patterns, minimizing overhead, and continuously monitoring performance. A few well-designed indexes are far better than many unused ones.

The above is the detailed content of Indexing Strategies for MongoDB. For more information, please follow other related articles on the PHP Chinese website!