Query Optimization

Create Indexes to Support Queries

Indexes store field values in a separate data structure. In read operations, MongoDB searches the index instead of scanning the entire collection. In write operations, MongoDB updates both the collection and the index.

Create indexes for your most common queries. If a query searches multiple fields, create a compound index.

For example, consider the following query on the type field in the inventory collection:

let typeValue = <someUserInput>;
db.inventory.find( { type: typeValue } );

To improve performance on this query, add an index on the type field.

db.inventory.createIndex( { type: 1 } )

[1] In mongosh, use db.collection.createIndex():

To analyze query performance, see Interpret Explain Plan Results.

Create Selective Queries

Query selectivity measures how well a query predicate filters documents and determines whether queries can use indexes effectively.

• Highly selective queries match fewer documents and use indexes more effectively. For instance, an equality match on _id is highly selective as it can match at most one document.

• Less selective queries match more documents and use indexes less efficiently.

For instance, the inequality operators $nin and $ne are not very selective since they often match a large portion of the index. As a result, in many cases, a $nin or $ne query with an index may perform no better than a $nin or $ne query that must scan all documents in a collection.

The selectivity of a regular expression depends on the expression itself. For details, see regular expression and index use.

Project Only Necessary Data

When you need a subset of fields from documents, you can improve performance by returning only the fields you need. Projections reduce network traffic and processing time.

For example, consider the following query to return only the timestamp, title, author, and abstract fields.

db.posts.find(
   {},
   { timestamp : 1, title : 1, author : 1, abstract : 1}
).sort( { timestamp : -1 } )

When you use a $project aggregation stage it should typically be the last stage in your pipeline, used to specify which fields to return to the client.

Using a $project stage at the beginning or middle of a pipeline to reduce the number of fields passed to subsequent pipeline stages is unlikely to improve performance, because the database performs this optimization automatically.

For more information, see Project Fields to Return from Query.

db.inventory.createIndex( { type: 1, _id: 1, price: 1, item: 1, expiryDate: 1} )

db.inventory.aggregate([
  { $match: {type: "food", expiryDate: { $gt: ISODate("2025-07-10T00:00:00Z") }}},
  { $sort: { item: 1 }},
  { $project: { _id: 1, price: 1} }
])

Limit Query Results

MongoDB cursors return results in batches. If you know how many results you need, pass that value to the limit() method to reduce network resource usage.

Limit results after sorting so you know which documents are returned. For example, the following query returns only the 10 most recent results from the posts collection:

db.posts.find().sort( { timestamp : -1 } ).limit(10)

For more information, see limit().

Use Index Hints

The query optimizer selects the optimal index for a specific operation. However, you can force a specific index using the hint() method. This is useful for performance testing or when a field appears in several indexes and you need to guarantee which index MongoDB uses.

Use Server-Side Operations

Use the $inc operator to increment or decrement values in documents. The operator increments the field value on the server side, as an alternative to selecting a document, making simple modifications on the client side, and then writing the document to the server. Additionaly, the operator prevents race conditions when multiple application instances update the same field concurrently.

Run Covered Queries

A covered query is a query than can be satisfied entirely by an index without having to examine any documents. An index covers a query when all of the following are true:

• All the fields in the query (including fields specified by the application and any fields needed internally, such as for sharding) are part of the index.

• All the fields returned in the results are in the same index.

• No fields in the query are equal to null. For example, the following query predicates cannot result in covered queries:

  • { "field": null }

  • { "field": { $eq: null } }

db.inventory.createIndex( { type: 1, item: 1 } )

db.inventory.find(
   { type: "food", item:/^c/ },
   { item: 1, _id: 0 }
)

db.userdata.insertOne(
   { _id: 1, user: { login: "tester" } }
)

db.userdata.createIndex(
   { "user.login": 1 }
)

db.userdata.find(
   { "user.login": "tester" },
   { "user.login": 1, _id: 0 }
)