MongoDB explain output and plan stages

Parent: Global AI Hub Research Corpus · Published reference · snapshot 2026-10-19

Explain plan results for queries are subject to change between MongoDB versions. (from www.mongodb.com)

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

Stage meanings per MongoDB: COLLSCAN is a collection scan, IXSCAN an index scan, FETCH reads full documents, PROJECTION filters returned fields in memory, and SORT means documents were sorted in memory (or a covered index was used). A filter or sort that shows COLLSCAN would benefit from an index; docsExamined appears on COLLSCAN and FETCH stages and keysExamined on IXSCAN. [source]
Where `<string>>` is the field that is indexed and `<value>` is either the direction of the index, or the special index type such as `text` or `2dsphere`. See [index types](https://www.mongodb.com/docs/manual/core/indexes/index-types.md#std-label-index-types) for the full list of index types. [source]
- If the `$facet` stage is the first stage in a pipeline, the stage will perform a `COLLSCAN`. The `$facet` stage does not make use of indexes if it is the first stage in the pipeline. [source]
For example, in the following document, `metadata` is a good choice of `metaField` since it makes it easy to query data from a given weather sensor. Using these fields, MongoDB buckets readings from a single sensor together. [source]
The default name for an index is the concatenation of the indexed keys and each key's direction in the index (`1` or `-1`) using underscores as a separator. For example, an index created on `{ item : 1, quantity: -1 }` has the name `item_1_quantity_-1`. [source]

Structure and components

| Field | Description | Applicable Stages | | --- | --- | --- | | `docsExamined` | Specifies the number of documents scanned during the query execution stage. | `COLLSCAN`, `FETCH` | | `keysExamined` | For query execution stages that scan an index `keysExamined` is the total number of in-bounds and out-of-bounds keys that are examined in the process of the index scan. If the index scan consists of a single contiguous range of keys, only in-bounds keys need to be examined. If the index bounds consists of several key ranges, the index scan execution process may examine out-of-bounds keys in orde [source]
Starting in MongoDB 5.3, if the query planner selects a [clustered index](https://www.mongodb.com/docs/manual/reference/method/db.createcollection.md#std-label-db.createCollection.clusteredIndex) for a [clustered collection](https://www.mongodb.com/docs/manual/core/clustered-collections.md#std-label-clustered-collections) and the query contains bounds that define the portion of the index to search, the explain result includes a `CLUSTERED_IXSCAN` stage. The stage includes information about the clustered index key and index bounds. [source]
If the query planner selects a [clustered index](https://www.mongodb.com/docs/manual/reference/method/db.createcollection.md#std-label-db.createCollection.clusteredIndex) for a [clustered collection](https://www.mongodb.com/docs/manual/core/clustered-collections.md#std-label-clustered-collections) and the query *does not* contain bounds, the query performs an unbounded collection scan and the explain result includes a `COLLSCAN` stage. [source]
If the query planner selects a clustered index for a clustered collection and the query does not contain bounds, the query performs an unbounded collection scan and the explain result includes a COLLSCAN stage. [source]
Each stage consists of information specific to the stage. For example, an `IXSCAN` stage includes the index bounds along with other data specific to the index scan. If a stage has a child stage or multiple child stages, the stage will have an `inputStage` or `inputStages`. [source]
Each stage consists of information specific to the stage. For example, an `IXSCAN` stage includes the index bounds along with other data specific to the index scan. [source]
Contains *partial* execution information captured during the [plan selection phase](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) for both the winning and rejected plans. The field is present only if `explain` runs in `allPlansExecution` verbosity mode. [source]
The `explain` results present the query plans as a tree of stages. The output structure can differ based on which query engine the operation uses. Operations can use the classic query engine or the [slot-based execution query engine.](https://www.mongodb.com/docs/manual/reference/sbe.md#std-label-sbe-landing) [source]
If query settings are set, `querySettings` contains details about the query settings that are applied to the query shape. [source]
Contains information on the selection of the query plan by the [query optimizer.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization) [source]
The explain results present the query plans as a tree of stages. The output structure can differ based on which query engine the operation uses. Operations can use the classic query engine or the slot-based execution query engine. [source]
Contains statistics that describe the completed query execution for the winning plan. For write operations, completed query execution refers to the modifications that *would* be performed, but does *not* apply the modifications to the database. [source]
Total time in milliseconds required for query plan selection and query execution. It includes the time it takes to run the trial phase part of the plan selection process, but does not include the network time to transmit the data back to the client. [source]
If you run [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) on a `$setWindowsFields` operation, the output contains a `peakTrackedMemBytes` field that contains the maximum number of bytes of tracked memory in use. For more information, see [`explain.executionStats.peakTrackedMemBytes`.](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.peakTrackedMemBytes) [source]
[`explain.executionStats.totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalDocsExamined) refers to the total number of documents examined and *not* to the number of documents returned. For example, a stage can examine a document in order to apply a filter. If the document is filtered out, then it has been examined but will not be returned as part of the query result set. [source]
Contains resource consumption statistics, as long as they are not zero. The field is present only if `explain` runs in `executionStats` verbosity mode or higher and if `profileOperationResourceConsumptionMetrics` is enabled. [source]
Each `inputStage` can have another `inputStage` as a field. See [Explain Output Structure.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-output-structure) [source]
Each inputStage can have another inputStage as a field. See Explain Output Structure. [source]
For query execution stages that scan an index keysExamined is the total number of in-bounds and out-of-bounds keys that are examined in the process of the index scan. If the index scan consists of a single contiguous range of keys, only in-bounds keys need to be examined. If the index bounds consists of several key ranges, the index scan execution process may examine out-of-bounds keys in order to skip from the end of one range to the beginning of the next. [source]
Contains partial execution information captured during the plan selection phase for both the winning and rejected plans. The field is present only if explain runs in allPlansExecution verbosity mode. [source]
Specifies the number of "work units" performed by the query execution stage. Query execution divides its work into small units. A "work unit" might consist of examining a single index key, fetching a single document from the collection, applying a projection to a single document, or doing a piece of internal bookkeeping. [source]
For example, consider a query for `"item": "saccharomyces cerevisiae"` and `"stock": 60`. If the collection contains 10000 documents matching `"item": "saccharomyces cerevisiae"` and only 100 of those documents match `"stock": 60`, the query examines 10000 keys. In the `IXSCAN` stage, the query filters those keys by the `stock` field and only returns 100 results to the next stage. [source]
For example, with a granularity of `seconds`, MongoDB buckets documents within the same hour. If a bucket contains a document with a `metaField` value of `sensorA` and a `timeField` value of `2024-08-01T18:23:21Z`, an incoming document with a `metaField` of `sensorB` goes into a separate bucket regardless of time. An incoming document from `sensorA` goes into the same bucket only if its `timeField` is between `2024-08-01T18:00:00Z` and `2024-08-01T18:59:59Z`. [source]
- The [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) command [results](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) contain a new `BATCHED_DELETE` stage for batched document deletions. [source]
The bounds of an index scan define the parts of an index to search during a query. The computation of multikey index bounds follows special rules. For details, see Multikey Index Bounds. [source]
The bounds of an index scan define the parts of an index to search during a query. The computation of multikey index bounds follows special rules. For details, see [Multikey Index Bounds.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/multikey-index-bounds.md#std-label-indexes-multikey-bounds) [source]
The explain command results contain a new BATCHED_DELETE stage for batched document deletions. [source]
For more information about the differences in explain results between query engines, see [Explain Output Structure.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-output-structure) [source]
An array that contains statistics for the operations that are the input stages of the current stage. [source]
Object that contains two fields: true and false. Each field counts the number of matching queries where the value of usedDisk is true or false, respectively. [source]
| Field | Necessity | Description | | --- | --- | --- | | [field](https://www.mongodb.com/docs/manual/reference/operator/aggregation/densify.md#std-label-densify-field) | Required | The field to densify. The values of the specified `field` must either be all numeric values or all dates. Documents that do not contain the specified `field` continue through the pipeline unmodified. To specify a `<field>` in an embedded document or in an array, use [dot notation.](https://www.mongodb.com/docs/manual/core/document.md#std-label-document-dot-notation) For restrictions, see [`field` Restrictions.](htt [source]
In prior versions, [`$densify`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/densify.md#mongodb-pipeline-pipe.-densify) treats bounds with an equal lower and upper bound as a closed interval and generates a document with the bound value as a field value if the collection does not already contain a document with the bound value. [source]

How it works

The Atlas docs' worked example: a log line with planSummary COLLSCAN, keysExamined 0, docsExamined 10000, nreturned 4 gives a ratio of 2500. Atlas names a missing index or an index that only partially supports the query as the typical cause, and recommends Performance Advisor, Query Shape Reports and Query Targeting metrics for follow-up. [source]
The time reported by `explain.executionStats.executionTimeMillis` is not necessarily representative of actual query time. During steady state operations (when the query plan is cached), or when using [`cursor.hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) with `cursor.explain()`, MongoDB bypasses the plan selection process, resulting in a faster actual time, leading to a lower `explain.executionStats.executionTimeMillis` value. [source]
| Counter | Description | | --- | --- | | `collscan``clusteredCollscan` | Collection scans, counted separately based on whether the scan uses the [clustered index.](https://www.mongodb.com/docs/manual/core/clustered-collections.md#std-label-clustered-collections) | | `coveredIxscan` | Index scans that don't fetch documents. | | `ixscanFetch` | Index scans that fetch documents. | | `countScan` | Scans that count index keys without returning documents. | | `distinctScan``distinctScanFetch` | Scans that skip duplicate index keys, counted separately based on whether the scan fetches documents. | | [source]
When totalKeysExamined is far lower than totalDocsExamined, the docs say to inspect each stage in executionStats.executionStages and compare keysExamined with docsExamined per stage to find which stage failed to use the index. A totalKeysExamined of 0 with large totalDocsExamined indicates a pure collection scan. [source]
keysExamined counts both in-bounds and out-of-bounds keys. When index bounds have several key ranges, the scan examines out-of-bounds keys to skip from one range to the next, so keysExamined can exceed the matching key count without the index being bad. [source]
As with any hash function, two different plan cache query shapes may result in the same hash value. However, the occurrence of hash collisions between different plan cache query shapes is unlikely. [source]
Because the query shapes are the same, the explain output has the same queryShapeHash for each of the examples, and the same planCacheShapeHash for each. For example: [source]
Because the query shape is different from the shape in the previous section, the explain output has a different queryShapeHash from the previous example, and a different planCacheShapeHash. For example: [source]
Float that represents the estimated number of index keys that the query planner predicts the plan to process. [source]
A cached plan is replanned when its re-run trial does more than internalQueryCacheEvictionRatio (reported default 10) times the work of the original trial. In SBE, SERVER-85238 uses this ratio as a multiplier on the winner's totalKeysExamined + totalDocsExamined as the replanning read budget. The default of 10 comes only from a third-party slide deck, not official docs. [source]
When you create an index, you can give the index a custom name. Giving your index a name helps distinguish different indexes on your collection. For example, you can more easily identify the indexes used by a query in the query plan's [explain results](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) if your indexes have distinct names. [source]
Starting in MongoDB 8.3, multi-planning with a CBR backup is the default plan selection mechanism for eligible queries. For a short trial period, the multi-planner attempts to find a plan capable of returning a result set within this short timeframe. If the attempt is unsuccessful, MongoDB applies a set of rules to determine whether the multi-planner should continue or if CBR should evaluate each node in the plan to determine the optimal plan. [source]
When you sort based on an array field that is indexed with a multikey index, the query plan includes an in-memory sort stage unless both of the following are true: [source]
`notablescan` does not allow unbounded queries that use a clustered index because the queries require a full collection scan. For more information, see [Collection Scans.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-output-collection-scan) [source]
- [`executionStats.totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalKeysExamined) displays `3809` to indicate that MongoDB scanned 3,809 index entries. The number of keys examined match the number of documents returned, meaning that the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) only had to examine index keys to return the results. The [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) did not have to scan all [source]
When the slot-based query execution engine is used for [`$group`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/group.md#mongodb-pipeline-pipe.-group), the [explain results](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) include `queryPlanner.winningPlan.queryPlan.stage: "GROUP"`. [source]
When the slot-based query execution engine is used for [`$lookup`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup.md#mongodb-pipeline-pipe.-lookup), the [explain results](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) include `queryPlanner.winningPlan.queryPlan.stage: "EQ_LOOKUP"`. `EQ_LOOKUP` means "equality lookup". [source]
- `heuristics`: Uses a set of rules to determine selectivity. Only used when sampling fails. [source]
- If the `$facet` stage comes later in the pipeline and earlier stages have used indexes, `$facet` will not trigger a `COLLSCAN` during execution. [source]
For example, [`$match`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/match.md#mongodb-pipeline-pipe.-match) or [`$sort`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/sort.md#mongodb-pipeline-pipe.-sort) stages that come before a `$facet` stage can make use of indexes and the `$facet` will not trigger a `COLLSCAN`. [source]
With Queryable Encryption, MongoDB tracks the occurrences of each field/value pair in an encrypted collection using an internal counter. The [contention factor](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-contention-factor) partitions this counter, similar to an array. This minimizes issues with incrementing the counter when using `insert`, `update`, or `findAndModify` to add or modify an encrypted field with the same field/value pair in close succession. `contention = 0` creates an array with one element at index 0. `contention = 4` creates an array with 5 elements at i [source]
Last point queries are most performant when they use the [DISTINCT\_SCAN optimization](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results). This optimization is only available when an index on `timeField` is descending. [source]
Bounds intersection refers to the point where multiple bounds overlap. For example, given the bounds `[ [ 3, Infinity ] ]` and `[ [ -Infinity, 6 ] ]`, the intersection of the bounds results in `[ [ 3, 6 ] ]`. [source]
Because the query uses `$elemMatch` to join these predicates, MongoDB intersects the bounds to: [source]
Because the preceding query does not use `$elemMatch`, MongoDB does not intersect the bounds. Instead, MongoDB uses either of the following bounds: [source]
When an index covers a query, the explain result has an `IXSCAN` stage that is **not** a descendant of a `FETCH` stage. [source]
Limits how many digits after the decimal point are taken into account when querying a `double` or `decimal` field. Additional digits are dropped, not rounded. For example, a `precision` of 1 treats `10.18` as `10.1` for queries. The encrypted value is still stored as `10.18`. [source]
When unset, `contention` defaults to `8`, which provides high performance for most workloads. Higher contention improves the performance of insert and update operations on low cardinality fields, but decreases find performance. [source]
Because `metaField` values must match exactly to group documents, the number of buckets in a time series collection depends on the number of unique `metaField` values. Collections with fine-grained or changing `metaField` values generate many sparsely packed, short-lived buckets. This leads to decreased storage and query efficiency. [source]
4. Queryable Encryption implements a fast, searchable scheme that allows the server to process queries on fully encrypted data, without knowing anything about the data. The data and the query itself remain encrypted at all times on the server. [source]
Setting [`cursorTimeoutMillis`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.cursorTimeoutMillis) to less than or equal to `0` results in all cursors being immediately eligible for timeout. Generally, the timeout value should be greater than the average amount of time for a query to return results. Use tools like the [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) cursor modifier to analyze the average query time and select an appropriate timeout period. [source]
**Index bounds** define the range of index values that MongoDB searches when using an index to fulfill a query. When you specify multiple query predicates on an indexed field, MongoDB attempts to combine the bounds for those predicates to produce an index scan with smaller bounds. Smaller index bounds result in faster queries and reduced resource use. [source]
Compound bounds combine bounds for multiple keys of a [compound index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound.md#std-label-index-type-compound). Using bounds from multiple keys reduces the time it takes to process a query because MongoDB does not need to compute results for each bound individually. [source]
The following example shows how MongoDB uses compound bounds when an index includes a non-array field and multiple array fields. [source]
The fields `"ratings.scores.q1"` and `"ratings.scores.q2"` share the field path `"ratings.scores"`. In order to compound index bounds, a query must use `$elemMatch` on the common field path. [source]
Specifies the *inclusive* lower bound for a specific index in order to constrain the results of [`find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find.md#mongodb-method-db.collection.find). [`min()`](https://www.mongodb.com/docs/manual/reference/method/cursor.min.md#mongodb-method-cursor.min) provides a way to specify lower bounds on compound key indexes. [source]
The Explain Plan doesn't show aggregation pipeline stages such as [`$merge`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/merge.md#mongodb-pipeline-pipe.-merge) and [`$out`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/out.md#mongodb-pipeline-pipe.-out) because Atlas ignores all out stages from the aggregation before running the explain plan. [source]
Index scans, counted separately by the index bounds that the scan uses. MongoDB increments boundsMixture when the scan uses more than one type of bound. [source]
`$in` compares each parameter to each document in the collection, which can cause performance issues. To improve performance, create an index on the `field` you want to query. An index allows MongoDB to create bounds for each `$in` element and search more efficiently. [source]
For example, `$group` operations of the following form can result in a `DISTINCT_SCAN`: [source]
Number of post-recovery waits that completed when the cluster's config time advanced since the server started. [source]
usedDisk is true when the query writes data to temporary files due to memory restrictions. [source]
MongoDB follows prevaling database usage and works with time in UTC. The `dateSubtract` expression always takes a `startDate` in UTC and returns a result in UTC. If the `timezone` is specified, the calculation will be done using the specified `timezone`. The timezone is especially important when a calculation involves Daylight Savings Time (DST). [source]
- When you specify Polygon `coordinates`, the first and last coordinates in the array must be the same. This closes the bounds of the polygon. [source]
The sort direction is descending because the `sortBy` value is "-1". [source]

How-to and procedures

To see whether MongoDB will apply an index filter for a plan cache query shape, check the [`indexFilterSet`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.indexFilterSet) field of either the [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) or the [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) method. [source]
Use the [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) or the [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) method in [executionStats](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#std-label-explain-method-executionStats) mode to return statistics about the query process, including the index used, the number of documents scanned, and the time the query takes to process in milliseconds. [source]
Run [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) or the [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) method in [allPlansExecution](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#std-label-explain-method-allPlansExecution) mode to view partial execution statistics collected during plan selection. [source]
To compare candidate indexes, run the same query with hint() and explain('executionStats') and compare totalKeysExamined. In the MongoDB docs example, {year:1, rated:1} scanned 246 keys for 235 results while {rated:1, year:1} scanned 235, so the second is more efficient (equality field before range field). [source]
To view the query plan selected, chain the [`cursor.explain("executionStats")`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) cursor method to the end of the **find** command: [source]
To view the MongoDB 8.0 queryShapeHash and planCacheShapeHash hexadecimal strings, you can use the explain command. [source]
To hide a text index, you must specify the index by `name` and not by `keyPattern`. [source]
To view the execution statistics for a specific index, append to the [`db.collection.find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find.md#mongodb-method-db.collection.find) the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) method followed by [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain), e.g.: [source]
To manually compare the performance of a query using more than one index, you can use the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) method in conjunction with the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) method. [source]
To manually compare the performance of a query using more than one index, you can use the hint() method in conjunction with the explain() method. [source]
To determine whether a pipeline uses indexes, review the query plan and look for `IXSCAN` or `DISTINCT_SCAN` plans. [source]
To add query settings and explore examples, which include `explain()` output with `querySettings`, see [`setQuerySettings`.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) [source]
To view the query plan information for a given query, you can use [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) or the [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) . [source]
To view the query plan statistics, use the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) method: [source]
To analyze query performance, see [Interpret Explain Plan Results.](https://www.mongodb.com/docs/manual/tutorial/analyze-query-plan.md) [source]
To see whether your operation results in a `DISTINCT_SCAN`, check your operation's [explain results.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) [source]
To see how many documents were scanned to return the query, view the query's [`executionStats`:](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-executionStats) [source]
To add query settings and explore examples, which include explain() output with querySettings, see setQuerySettings. [source]
To analyze query performance, see Interpret Explain Plan Results. [source]
To confirm whether a query used an index, run the query with the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) option. [source]
Create a [compound multikey index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound.md#std-label-index-type-compound) on the `item` and `ratings` fields: [source]
To compound the bounds for `"ratings.score"` with the bounds for `"ratings.by"`, the query must use `$elemMatch`. [source]
Create a compound index on the `ratings.score` and the `ratings.by` fields: [source]
Create a compound index on the `ratings.scores.q1` and the `ratings.scores.q2` fields: [source]
To compound the bounds, the query must use `$elemMatch` on the common path `"ratings.scores"`: [source]
To confirm that the sort operation used the Secondary Index, run the operation again with the `.explain( "executionStats" )` option: [source]
To confirm that the last point query used the secondary index, run the operation again using `.explain( "executionStats" )`: [source]
To view a step-by-step guide demonstrating how to use a remote KMS with Queryable Encryption, see [Queryable Encryption Tutorials.](https://www.mongodb.com/docs/manual/core/queryable-encryption/tutorials.md#std-label-qe-tutorial-automatic-encryption) [source]
To view a list of all supported KMS providers, see [KMS Providers.](https://www.mongodb.com/docs/manual/core/queryable-encryption/fundamentals/kms-providers.md#std-label-qe-fundamentals-kms-providers) [source]
To learn more about why you should use a remote KMS, see [Reasons to Use a Remote Key Management System.](https://www.mongodb.com/docs/manual/core/queryable-encryption/fundamentals/kms-providers.md#std-label-qe-reasons-to-use-remote-kms) [source]
To learn how MongoDB combines multikey index bounds to improve performance, see Multikey Index Bounds. [source]
To help you better understand the performance of your pipeline, you can view your pipeline's explain plan. You can view the explain plan at any point while creating or editing your pipeline. [source]
To view your full explain plan as raw JSON, select the Raw Output view. [source]
To help you better understand the performance of your query, you can view your query's explain plan. [source]
Create a 2d index on the `address` field. Specify the following location bounds: [source]
To use [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain), append one of the aforementioned methods to [`db.collection.explain()`:](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) [source]
To see the list of operations supported by [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain), run: [source]
To determine whether a query is a covered query, use the db.collection.explain() or the explain() method. See Covered Queries. [source]
To determine whether a query is a covered query, use the [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) or the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) method. See [Covered Queries.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-output-covered-queries) [source]
To learn about important explain result fields and how to interpret them, see [Interpret Explain Plan Results.](https://www.mongodb.com/docs/manual/tutorial/analyze-query-plan.md#std-label-interpret-explain-plan) [source]
To learn about important explain result fields and how to interpret them, see Interpret Explain Plan Results. [source]
To learn how Queryable Encryption works, see [Queryable Encryption Fundamentals.](https://www.mongodb.com/docs/manual/core/queryable-encryption/fundamentals.md#std-label-qe-fundamentals) [source]
To learn how project works, see the `project` entry in the [MongoDB Manual.](https://www.mongodb.com/docs/manual/reference/method/db.collection.find.md#std-label-find-projection) [source]
Use `kyber` to run multiple workloads in the same VM or in your own data center. `kyber` improves the I/O interpolation under contention, and reduces the impact of noisy neighbors. Additionally, `kyber` works efficiently in self hosted situations, such as on-premises virtualization and collocated workloads in one large cloud VM. However, `kyber` is only available on linux kernels starting in version 4.12. [source]
Avoid modifying the [`wiredTigerEngineRuntimeConfig`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.wiredTigerEngineRuntimeConfig) unless under the direction from MongoDB engineers as this setting has major implication across both WiredTiger and MongoDB. [source]

Examples and snippets

```javascript — `"op" : "query",` … [source]
````text — `## Summary` … [source]
```javascript — `"t":{` … [source]
```javascript — `"t": {` … [source]
```javascript — `queryPlanner: {` … [source]
```javascript — `queryPlanner: {` … [source]
```json — `<Timestamp> COMMAND <query>` … [source]
```none — `"version" : 1,` … [source]
```javascript — `"t":{"$date":"2026-08-14T13:36:19.194-04:00"},"s":"D1",` … [source]
```javascript — `winningPlan: {` … [source]
```javascript — `executionStats: {` … [source]
```javascript — `version: '2',` … [source]
```text — `"explainVersion": "1",` … [source]
```javascript — `db.people.find(` … [source]
```javascript — `db.people.explain("executionStats").find(` … [source]
```javascript — `db.runCommand( {` … [source]
```javascript — `// Query Operation 1` … [source]
```javascript — `// Query Operation 2` … [source]
```javascript — `db.<collection>.dropIndex("<indexName>")` … [source]
```javascript — `db.movies.explain().count( { year: { $gt: 2000 } } )` … [source]
```javascript — `db.pizzaOrders.explain().find(` … [source]
```javascript — `db.pizzaOrders.explain().find(` … [source]
```javascript — `db.movies.explain().find( { rated: "PG" } ).finish().queryPlanner.winningPlan` … [source]
```javascript — `db.runCommand( {` … [source]
```javascript — `db.movies.find(` … [source]
```javascript — `key: {` … [source]
```javascript — `{ // Plan Cache Entry 1` … [source]
```java — `var explainCommand = new Document("explain", new Document()` … [source]
```javascript — `db.sensorData.explain( "executionStats" ).aggregate( [` … [source]
```javascript — `db.getCollection( 'sensorData' ).explain( "executionStats" ).aggregate( [` … [source]
```javascript — `const explainResult = await database.command({` … [source]
```python — `explain_result = database.command(` … [source]
```csharp — `// Indexes on ``timeField`` descending are more performant because they` … [source]
```java — `// Indexes on ``timeField`` descending are more performant because they` … [source]
```javascript — `// Indexes on ``timeField`` descending are more performant because they` … [source]
```python — `# Indexes on ``timeField`` descending are more performant because they` … [source]
```javascript — `db.runCommand(` … [source]
```javascript — `db.runCommand({` … [source]
```text — `atlas clusters search indexes create [indexName] [options]` … [source]
```javascript — `db.collection.find().explain()` … [source]
```none — `db.collection.explain().<method(...)>` … [source]
```javascript — `db.movies.explain().remove( { rated: "PG" }, { justOne: true } )` … [source]
```javascript — `db.movies.explain().aggregate(` … [source]
```text — `Interpret this explain plan for me.` … [source]
```text — `atlas deployments search indexes create [indexName] [options]` … [source]
```javascript — `db.products.find(` … [source]
```javascript — `db.movies.explain( "allPlansExecution" ).findAndModify( {` … [source]
```javascript — `var cursor = db.users.find(` … [source]
```javascript — `db.inventory.find(` … [source]
```none — `'$lookup': {` … [source]
```javascript — `stage: 'OR',` … [source]
```javascript — `db.runCommand(` … [source]
```none — `$densify: {` … [source]
```javascript — `db.weather.aggregate( [` … [source]
```javascript — `db.coffee.aggregate( [` … [source]
```javascript — `db.coffee.aggregate( [` … [source]
```python — `client = MongoClient(CONNECTION_STRING)` … [source]
```javascript — `"ns" : <string>,` … [source]
```javascript — `timestamp: ISODate("2024-06-17T10:00:00Z"),` … [source]
```shell — `atlas api atlasSearch deleteIndexByName --version 2024-05-30 --clusterName [clusterName] --collectionName [col` … [source]
```javascript — `db.<collection>.aggregate(` … [source]
```javascript — `db.<collection>.createIndex(` … [source]
```javascript — `db.getSiblingDB("examples").runCommand(` … [source]

Measurements and reference values

nreturned:4 protocol:op_query 358ms [source]
For example, on a system with a total of 4GB of RAM the WiredTiger cache uses 1.5GB of RAM (`0.5 * (4GB - 1GB) = 1.5 GB`). When providing a specific cache size ensure the RAM does not exceed the bounds of 0.256GB to 10000GB. [source]

Problems, failure modes and limitations

| Field | Description | | --- | --- | | `version` | A number that indicates the query engine used to complete the query. `1` indicates that the classic engine was used.; `2` indicates that the [slot-based query execution engine](https://www.mongodb.com/docs/manual/reference/sbe.md#std-label-sbe-landing) was used. | | `createdFromQuery` | A document that contains the specific query that resulted in this cache entry. For example: `{ "query" : <document>, "sort" : <document>, "projection" : <document> }` | | `isActive` | A boolean that indicates whether the entry is active or inactive. If active, [source]
| Field | Type | Literal or Normalized | Description | | --- | --- | --- | --- | | `key` | Document | Literal | Contains the query shape and additional query attributes that group a set of queries together | | `key.queryShape` | Document | Literal | Contains attributes used to group similar queries together. For more information, see [Query Shape.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#std-label-queryStats-queryShape) | | `key.client` | Document | Literal | Describes client information associated with the key | | `key.client.application` | Document | [source]
| **MongoDB Version** | **Changes** | | --- | --- | | 6.1 | Slow operation log messages include [cache refresh time fields.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-cache-refresh-times) | | 6.2 | Slow operation log messages include a `queryFramework` field that indicates which query engine executed the query: `queryFramework: "classic"` indicates that the classic engine executed the query.; `queryFramework: "sbe"` indicates that the slot-based query execution engine executed the query. | | 6.3 | Slow operation log messages and [database profiler](ht [source]
Before dropping, check prefix redundancy (a compound index { a:1, b:1 } serves queries on { a:1 }), and after dropping watch the slow-query log for COLLSCAN and verify critical query shapes with explain('executionStats'), since the planner may switch to a different existing index. [source]
planSummary is a string in both system.profile documents and slow-query log entries that summarises the winning plan (e.g. 'COLLSCAN' or 'IXSCAN { a: 1, _id: -1 }'). A COLLSCAN with keysExamined 0 and docsExamined far above nreturned signals a missing index; the docsExamined:docsReturned ratio near 1:1 is ideal. [source]
| Method | Availability | Description | | --- | --- | --- | | Use the Atlas Query Profiler | M10+ Atlas clusters | The Atlas Query Profiler shows long-running operations and performance statistics. For more information, see [Monitor Query Performance with the Query Profiler.](https://www.mongodb.com/docs/atlas/tutorial/query-profiler.md#std-label-profile-database) | | Enable the Database Profiler | Atlas clusters and self-hosted deployments | When enabled, the database profiler stores information about slow queries in the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system- [source]
When a query shape has query knobs set through setQuerySettings or setParameter, slow query log entries include a queryKnobs document. The document shows the effective value of each knob and where the value comes from, with the same shape as the explain output. For details, see Query Knobs. [source]
A SORT stage means an in-memory sort. In stages that can spill, usedDisk true (added in 5.3) shows the sort went to disk, which is slow; the usual fix is a compound index whose order supports the sort so the SORT stage disappears. [source]
From 8.0 the explain output carries planCacheShapeHash (a copy of queryHash, which is deprecated and slated for removal) and planCacheKey. planCacheKey depends on both the plan cache query shape and the available indexes. [source]
Starting in MongoDB 8.0, the existing `queryHash` field is duplicated in a new field named `planCacheShapeHash`. If you're using an earlier MongoDB version, you'll only see the `queryHash` field. Future MongoDB versions will remove the deprecated `queryHash` field, and you'll need to use the `planCacheShapeHash` field instead. [source]
A hexadecimal string that represents the hash of the [plan cache query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) and is dependent only on the plan cache query shapes. `planCacheShapeHash` can help identify slow queries (including the query filter of write operations) with the same plan cache query shape. [source]
- If `false` or `0`, the stage may still have results to return. For example, consider a query with a limit whose execution stages consists of a `LIMIT` stage with an input stage of `IXSCAN` for the query. If the query returns more than the specified limit, the `LIMIT` stage will report `isEOF: 1`, but its underlying `IXSCAN` stage will report `isEOF: 0`. [source]
To check if MongoDB must perform an in-memory sort, append cursor.explain() to the query and check the explain results. If the query plan contains a SORT stage, then MongoDB must perform an in-memory sort operation subject to the 100 megabyte memory limit. [source]
| Index Property | Description | | --- | --- | | `expireAfterSeconds` | The number of seconds that determines the expiration threshold of a [TTL Collection.](https://www.mongodb.com/docs/manual/tutorial/expire-data.md#std-label-ttl-collections) If successful, the command returns a document that contains: `expireAfterSeconds_new`, the new value for `expireAfterSeconds`; `expireAfterSeconds_old`, the old value for `expireAfterSeconds`, if the index had a value for `expireAfterSeconds` before. Modifying the index option `expireAfterSeconds` resets the [`$indexStats`](https://www.mongodb.com/docs/ [source]
If MongoDB cannot use an index or indexes to obtain the sort order, the results include a `SORT` stage indicating an in-memory sort operation. If the explain plan does not contain an explicit `SORT` stage, then MongoDB used an index to obtain the sort order. [source]
| Field | Type | Description | | --- | --- | --- | | [setIndexCommitQuorum](https://www.mongodb.com/docs/manual/reference/command/setindexcommitquorum.md#std-label-setIndexCommitQuorum-cmd-coll) | `string` | The name of the collection for which the indexes are being built. | | [indexNames](https://www.mongodb.com/docs/manual/reference/command/setindexcommitquorum.md#std-label-setIndexCommitQuorum-cmd-indexNames) | `array` | An array of in-progress index builds to modify. Each element of the array must be the *name* of the index. The indexes specified to `indexNames` must be the entire set of i [source]
| Field | Type | Description | | --- | --- | --- | | `key` | document | Specifies the index's fields. For each field, specify a key-value pair in which the key is the name of the field to index and the value is either the index direction or [index type](https://www.mongodb.com/docs/manual/core/indexes/index-types.md#std-label-index-types). If specifying direction, specify `1` for ascending or `-1` for descending. MongoDB supports several different index types, including: [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text.md#std-label-index-feature-text); [geospatial [source]
MongoDB automatically enables block processing for eligible time series queries. You cannot manually specify whether a query uses block processing. To see if your time series query uses block processing, see [`stages`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.winningPlan.slotBasedPlan.stages) in the explain plan output. [source]
However, the following query operation, which by default uses the "simple" binary collator, cannot use the index and requires a `COLLSCAN`. [source]
| `$exists` Query | Using a Sparse Index | Using a Non-Sparse Index | | --- | --- | --- | | `{ $exists: true }` | Most efficient. MongoDB can make an exact match and does not require a `FETCH`. | More efficient than queries without an index, but still requires a `FETCH`. | | `{ $exists: false }` | Cannot use the index and requires a `COLLSCAN`. | Requires a `FETCH`. | [source]
Cannot use the index and requires a COLLSCAN. [source]
Slow query log messages contain new metrics if the query execution writes temporary files to disk. These metrics are prefixed by the query execution stage that caused the query to exceed the memory limit. For example, sortSpills indicates the number of times that the sort stage of query execution wrote temporary files to disk. [source]
Specify `precision` and limit it when possible. Every digit increases storage overhead and has a high impact on searchable range and index generation. [source]
| Parameter | Type | Description | | --- | --- | --- | | `wildcardProjection` | document | Optional. Allows users to include or exclude specific field paths from a [wildcard index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) This option is only valid when you create an [wildcard index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) on all document fields. You cannot specify the `wildcardProjection` option when you create a wildcard index on a specific field path and [source]
If the query does not join the conditions on the array field with `$elemMatch`, MongoDB cannot intersect the multikey index bounds. [source]
If MongoDB cannot compound the two bounds, MongoDB constrains the index scan by the bound on the leading field. In this example, the leading field is `temperature`, resulting in a constraint of `temperature: [ [ 80, Infinity ] ]`. [source]
If your query specifies `$elemMatch` on fields that diverge from a common path, MongoDB **cannot** compound the bounds of index keys from the same array. [source]
MongoDB cannot compound the index bounds and the `"ratings.scores.q2"` field is unconstrained during the index scan. [source]
| Parameter | Type | Description | | --- | --- | --- | | `keyPatterns` | document | An array containing index specification documents. Each document contains field and value pairs where the field is the index key and the value describes the type of index for that field. For an ascending index on a field, specify a value of `1`; for descending index, specify a value of `-1`. .. include:: /includes/indexes/wildcard-use-wc-methods.rst | | `options` | document | Optional. A document that contains a set of options that controls the creation of the indexes. See [Options](https://www.mongodb.com/docs [source]
"Range" filters scan fields. The scan doesn't require an exact match, which means range filters are loosely bound to index keys. To improve query efficiency, limit the range bounds and use equality matches to reduce the number of documents to scan. [source]
Explain output is limited by the maximum [Nested Depth for BSON Documents](https://www.mongodb.com/docs/manual/reference/limits.md#mongodb-limit-Nested-Depth-for-BSON-Documents), which is 100 levels of nesting. Explain output that exceeds the limit is truncated. [source]
If the index does not exist, the command errors with the message `"cannot find index <name|keyPattern> for ns <db.collection>"`. [source]
Sort stages, counted separately by sort type and by whether the sort has a limit. [source]
If the argument resolves to a value of `null` or refers to a field that is missing, [`$asin`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/asin.md#mongodb-expression-exp.-asin) returns `null`. If the argument resolves to `NaN`, [`$asin`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/asin.md#mongodb-expression-exp.-asin) returns `NaN`. If the argument resolves to a value outside the bounds of `[-1, 1]` inclusive, [`$asin`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/asin.md#mongodb-expression-exp.-asin) throws an error. [source]
Specify minimum and maximum (inclusive) queryable values for a field when possible, as smaller bounds improve query efficiency. If querying values outside of these bounds, MongoDB returns an error. [source]
| Field | Type | Description | | --- | --- | --- | | [min and max](https://www.mongodb.com/docs/manual/core/queryable-encryption/fundamentals/encrypt-and-query.md#std-label-qe-field-min-max) | Same as field `bsonType` | Required if `bsonType` is `decimal` or `double`. Optional but highly recommended if it is `int`, `long`, or `date`. Defaults to the minimum and maximum values of the `bsonType`. When possible, specifying bounds on a query improves performance. If querying values outside of these inclusive bounds, MongoDB returns an error. | [source]
If the argument resolves to a value of `null` or refers to a field that is missing, [`$acos`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/acos.md#mongodb-expression-exp.-acos) returns `null`. If the argument resolves to `NaN`, [`$acos`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/acos.md#mongodb-expression-exp.-acos) returns `NaN`. If the argument resolves to a value outside the bounds of `[-1, 1]` inclusive, [`$acos`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/acos.md#mongodb-expression-exp.-acos) throws an error. [source]

Comparisons and alternatives

| Field | Field Type | Necessity | Description | | --- | --- | --- | --- | | `setQuerySettings` | document or string | Required | You can provide either: The same fields as those in a [`find`](https://www.mongodb.com/docs/manual/reference/command/find.md#mongodb-dbcommand-dbcmd.find), [`distinct`](https://www.mongodb.com/docs/manual/reference/command/distinct.md#mongodb-dbcommand-dbcmd.distinct), or [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate) command, and a `$db` field with the database associated with the original command [source]
A low docsExamined/nReturned ratio does not guarantee a fast query: a non-selective index can be slower than a scan, and a query that returns a large share of the collection may rightly choose a COLLSCAN. IXSCAN with high cost usually points to index selectivity rather than a missing index. [source]
| Option | Description | | --- | --- | | allowDiskUse | Whether or not pipelines that require more than 100 megabytes of memory to execute write to temporary files on disk. For details, see [`cursor.allowDiskUse()`.](https://www.mongodb.com/docs/manual/reference/method/cursor.allowdiskuse.md#mongodb-method-cursor.allowDiskUse) | | allowPartialResults | For queries against a sharded collection, allows the command (or subsequent getMore commands) to return partial results, rather than an error, if one or more queried shards are unavailable. | | awaitData | If the cursor is a a tailable-await cur [source]
Unlike the [`explain.queryPlanner.planCacheShapeHash`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.planCacheShapeHash), the [`explain.queryPlanner.planCacheKey`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.planCacheKey) is a function of both the plan cache query shape and the currently available indexes for that shape. Specifically, if indexes that can support the query shape are added or dropped, the `planCacheKey` value may change but the `planCacheShapeHash` value wouldn't change. [source]
Recommended practice: compare explain('executionStats') (totalDocsExamined, executionTimeMillis) for hinted vs unhinted runs; use a hint to work around a stale cached plan or misleading selectivity, not as a permanent fix without addressing the missing or poorly designed index, since a forced index can worsen as data changes. [source]
For example, the following aggregation operation can be fulfilled by the tree of query plan execution rather than using the aggregation pipeline. [source]
- Keys Examined (`keysExamined`): Number of index keys scanned for the query. If this metric is `0` for a query that includes filter conditions, it's highly likely there is no index and MongoDB scanned the entire collection. This is a primary cause of slowness. If Docs Examined is very high and Keys Examined is `0` or very low compared to Docs Examined, you're likely scanning the collection or a very unselective index. To learn more, see [Indexes.](https://www.mongodb.com/docs/manual/indexes.md#std-label-indexes) [source]
The second compound index, `{ rated: 1, year: 1 }`, is therefore the more efficient index for supporting the example query, as the MongoDB server only needs to scan `235` [`index keys`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalKeysExamined) to find all matching documents using this index, compared to `246` when using the compound index `{ year: 1, rated: 1 }`. [source]
Fewer documents examined does not guarantee a faster query. Percona's sort example examined fewer documents but ran slower because an extra in-memory SORT stage was needed; Pythian's final index (129 keys vs 82) removed the SORT stage at the cost of a worse key ratio and ran 3 ms vs 2 ms. Check execution time and SORT stages alongside the ratios. [source]
| Parameter | Type | Description | | --- | --- | --- | | `unique` | boolean | Optional. Specifies that each index specified in the `keyPatterns` array is a [unique index](https://www.mongodb.com/docs/manual/core/index-unique.md#std-label-index-type-unique). Unique indexes will not accept insertion or update of documents where the index key value matches an existing value in the index. Specify `true` to create a unique index. The default value is `false`. The option is *unavailable* for [hashed indexes.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed.md#std-label-inde [source]
| Counter | Description | | --- | --- | | `collscanNoFilter``collscanWithFilter` | Collection scan stages, counted separately based on whether the stage applies a filter. | | `ixscanNoFilter``ixscanWithFilter` | Index scan stages, counted separately based on whether the stage applies a filter. | | `fetchNoFilter``fetchWithFilter` | Fetch stages, counted separately based on whether the stage applies a filter. | | `andHashNoFilter``andHashWithFilter` | Hash-based index intersection stages, counted separately based on whether the stage applies a filter. | | `andSorted` | Sorted index intersection [source]
`cursor.explain()` defaults to `queryPlanner`, unlike the [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) command, which defaults to `allPlansExecution`. [source]
| Field | Type | Description | | --- | --- | --- | | `scale` | number | Optional. The scale factor for the various size data. The `scale` defaults to 1 to return size data in bytes. To display kilobytes rather than bytes, specify a `scale` value of `1024`. If you specify a non-integer scale factor, MongoDB uses the integer part of the specified factor. For example, if you specify a scale factor of `1023.999`, MongoDB uses `1023` as the scale factor. Starting in version 4.2, the output includes the `scaleFactor` used to scale the size values. | | `indexDetails` | boolean | Optional. If `true`, [source]
[MongoDB Search](https://www.mongodb.com/docs/atlas/atlas-search/) offers advanced full-text search capabilities, including [configurable dynamic indexing](https://www.mongodb.com/docs/search/indexes/define-field-mappings.md#std-label-fts-configure-dynamic-mappings). We recommend using [MongoDB Search indexes](https://www.mongodb.com/docs/search/indexes/manage-indexes.md#std-label-fts-manage-indexes) instead of text indexes. [source]
If you run this example, the order of documents in your results might differ from the order of documents on this page because the aggregation pipeline does not contain a sort stage. [source]

Facts and statements

A boolean that specifies whether MongoDB applied an [index filter](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters) for the [plan cache query shape.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) [source]
executionStats.executionTimeMillis covers plan selection (including the trial phase) plus execution, excludes network transfer, and is not necessarily representative of real query time: with a cached plan or cursor.hint(), plan selection is bypassed and actual time is lower than the reported value. [source]
If the query planner selects an index, the explain result includes a `IXSCAN` stage. The stage includes information such as the index key pattern, direction of traversal, and index bounds. [source]
Explain output shape depends on the engine: classic-engine plans put the stage tree at winningPlan.stage with nested inputStage, while slot-based-engine (SBE) plans put it under winningPlan.queryPlan and carry a planNodeId per stage. The docs warn that examples mix both shapes and real output may differ significantly. [source]
The three explain('executionStats') counters used to judge an index are nReturned, totalKeysExamined and totalDocsExamined. A COLLSCAN shows totalKeysExamined 0 and totalDocsExamined equal to the collection size (21349 docs scanned to return 3809 in the MongoDB docs example). [source]
- [`queryPlanner.winningPlan.stage`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.winningPlan.stage) displays `COLLSCAN` to indicate a collection scan. [source]
MongoDB runs the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization) to choose the winning plan for the operation under evaluation. [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) returns the [`queryPlanner`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner) information for the evaluated method. [source]
If the query optimizer considered more than one plan, [`executionStats`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats) information also includes the *partial* execution information captured during the [plan selection phase](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) for both the winning and rejected candidate plans. [source]
planSummary: COLLSCAN keysExamined:0 [source]
If the `queryPlanner.winningPlan.inputStage.stage` is either `CLUSTERED_IXSCAN` or `IXSCAN`, the index was used. For more information on the explain plan output, see [Explain Results.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) [source]
The `winningPlan.queryPlan.inputStage.stage` is `DISTINCT_SCAN`, which indicates that the index was used. For more information on the explain plan output, see [Explain Results.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) [source]
- [`queryPlanner.winningPlan.inputStage.stage`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.winningPlan.inputStage) displays `IXSCAN` to indicate index use. [source]
The total number of index items scanned during queries and query-plan evaluation. This counter is the same as [`totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalKeysExamined) in the output of [`explain()`.](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) [source]
If MongoDB uses indexes for an [`$or`](https://www.mongodb.com/docs/manual/reference/operator/query/or.md#mongodb-query-op.-or) expression, the result will include the `OR` stage with an [`explain.queryPlanner.winningPlan.inputStages`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.winningPlan.inputStages) array that details the indexes; e.g.: [source]
For more information on `planCacheShapeHash` and `planCacheKey`, see [planCacheShapeHash and planCacheKey.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-hash-plan-cache-key) [source]
A boolean that indicates if the winningPlan is in the plan cache. [source]
The returned [`explain.executionStats`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats) information details the execution of the winning plan. To include `executionStats` in the results, you must run the explain in either: [source]
- [allPlansExecution](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#std-label-explain-method-allPlansExecution) verbosity mode. Use `allPlansExecution` mode to include partial execution data captured during [plan selection.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) [source]
Number of documents returned by the winning query plan. [`nReturned`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.nReturned) corresponds to the `n` field returned by `cursor.explain()` in earlier versions of MongoDB. [source]
Details the completed execution of the winning plan as a tree of stages; i.e. a stage can have an `inputStage` or multiple `inputStages`. [source]
- If you see `"planSummary": "COLLSCAN":` in the query log, the query performed a collection scan and did not use an index. This is a strong signal to add an [index](https://www.mongodb.com/docs/manual/indexes.md#std-label-indexes) or rewrite the query. [source]
If keysExamined is much higher than nreturned, the query scans many index keys; consider adjusting the index. For writes, keysExamined and docsExamined include reads from write-conflict retries, so they can exceed documents matched or modified. [source]
Number of documents examined during query execution. Common query execution stages that examine documents are `COLLSCAN` and `FETCH`. [source]
- [`executionStats.nReturned`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.nReturned) displays `3809` to indicate that the winning query plan returns 3,809 documents. [source]
The total number of documents scanned during queries and query-plan evaluation. This counter is the same as [`totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalDocsExamined) in the output of [`explain()`.](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) [source]
- [`executionStats`](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-executionStats), which details the execution of the winning plan and the rejected plans. [source]
The verbosity mode (i.e. `queryPlanner`, `executionStats`, `allPlansExecution`) determines whether the results include [`executionStats`](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-executionStats) and whether [`executionStats`](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-executionStats) includes data captured during [plan selection.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) [source]
| Subdocument | Description | | --- | --- | | `patterns` | Counts the overall shape of each winning plan. The patterns are mutually exclusive, so each query execution increments at most one pattern counter. | | `nodes` | Counts the types of plan stages that appear in each winning plan. The node counters are not mutually exclusive, so one query execution can increment several of them. | | `accessPaths` | Counts the data access paths and index bounds that each winning plan uses. The access path counters are not mutually exclusive, so one query execution can increment several of them. | [source]
If you see "planSummary": "COLLSCAN": in the query log, the query performed a collection scan and did not use an index. This is a strong signal to add an index or rewrite the query. [source]
[`explain.queryPlanner`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner) information details the plan selected by the [query optimizer.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization) [source]
These examples may combine the output structures of the classic and slot-based execution engines. They are not meant to be representative. Your output may differ significantly. [source]
Time in milliseconds the query planner spent on query optimization. This result doesn't include time spent optimizing inner [`$lookup`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup.md#mongodb-pipeline-pipe.-lookup) queries. [source]
A document that details the plan selected by the [query optimizer.](https://www.mongodb.com/docs/manual/core/query-plans.md) [source]
A document that details the plan selected by the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans.md). MongoDB presents the plan as a tree of stages. [source]
Array of candidate plans considered and rejected by the query optimizer. The array can be empty if there were no other candidate plans. [source]
queryPlanner.winningPlan.stage displays COLLSCAN to indicate a collection scan. [source]
If the query planner selects a collection scan, the explain result includes a `COLLSCAN` stage. [source]
The explain results for a query differ based on which query engine was used. For example, explain results for queries executed using the slot-based execution engine include the [`explain.queryPlanner.winningPlan.slotBasedPlan`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.winningPlan.slotBasedPlan) field. [source]
MongoDB runs the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization) to choose the winning plan, executes the winning plan to completion, and returns statistics describing the execution of the winning plan. [source]
"planSummary" : "COLLSCAN", [source]
- [`queryPlanner`](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-queryPlanner), which details the plan selected by the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization) and lists the rejected plans. [source]
```javascript [ { "opid": "12345", "secs_running": 5, "active": true, "ns": "sample_mflix.movies", "command": { "find": "movies", "filter": { "title": { "$regex": "The" } } }, "planSummary": "COLLSCAN", "locks": { ... }, "client": "203.0.113.25:43210" } ] ``` [source]
explain ignores existing plan cache entries and does not create a new one. A plan taken from the cache shows isCached: true in explain("executionStats") (per Percona), and fromPlanCache: true in the profiler. [source]
Number of index entries scanned. [`explain.executionStats.totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalKeysExamined) corresponds to the `nscanned` field returned by `cursor.explain()` in earlier versions of MongoDB. [source]
MongoDB documents a two-counter heuristic for a bad filter: if executionStats.totalDocsExamined is much greater than executionStats.nReturned, the index is ineffective; if the two are equal, MongoDB examined only the documents it returned, which indicates an effective index. [source]
Instead, MongoDB uses the wildcard index to support only one of the query predicates. MongoDB automatically chooses which predicate to support based on relevant wildcard index paths. The unsupported query predicates are shown in the [`rejectedPlans`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.queryPlanner.rejectedPlans) of the [explain results.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) [source]
In general, if [`keysExamined`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.keysExamined) is much higher than [`nreturned`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.nreturned), the database is scanning many index keys to find the result documents. Consider creating or adjusting indexes to improve query performance.. [source]
A boolean that indicates that the entire aggregation pipeline operation was optimized away, and instead, fulfilled by a tree of query plan execution stages. [source]
This field is `true` for a maximum of one plan between the winning plan and the rejected plans. If the query has no cached plan, the field is `false` for the winning plan and the rejected plans. [source]
A significant difference between the `numKeysEstimate` and the `costEstimate` can indicate issues with the `winningPlan`. [source]
Rejected plans have the same fields as `explain.queryPlanner.winningPlan`. [source]
Double that represents the score of the winning plan chosen by the multi-planner. [source]
MongoDB's docs warn that explain plan results are subject to change between MongoDB versions, so stored ratio baselines should be re-measured after upgrades. [source]
MongoDB runs the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans.md) to choose the winning plan and executes the winning plan to completion. In `"allPlansExecution"` mode, MongoDB returns statistics describing the execution of the winning plan as well as statistics for the other candidate plans captured during [plan selection.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) [source]
- [`executionStats.totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalKeysExamined) displays `0` to indicate that this query is not using an index. [source]
MongoDB scanned `246` index keys ([`executionStats.totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalKeysExamined)) to return `235` matching documents ([`executionStats.nReturned`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.nReturned)). [source]
MongoDB scanned `235` index keys ([`executionStats.totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalKeysExamined)) to return `235` matching documents ([`executionStats.nReturned`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.nReturned)). [source]
In some cases, the query planner uses a `DISTINCT_SCAN` index plan that returns one document per index key value. `DISTINCT_SCAN` executes faster than `IXSCAN` if there are multiple documents per key value. However, index scan parameters might affect the time comparison of `DISTINCT_SCAN` and `IXSCAN`. [source]
The cursor.explain("executionStats") and the db.collection.explain("executionStats") methods provide statistics about the performance of a query. These statistics can be useful in measuring if and how a query uses an index. See db.collection.explain() for details. [source]
queryPlanner.winningPlan.inputStage.stage displays IXSCAN to indicate index use. [source]
The number of index keys examined is indicated in the [`totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalKeysExamined) field. Queries that examine more index keys generally take longer to complete. [source]
A hash of the key for the plan cache entry associated with the query. [source]
By default, [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) runs in `queryPlanner` verbosity mode. [source]
The following example runs [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) in `"queryPlanner"` verbosity mode to return the query planning information for the specified [`count()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.count.md#mongodb-method-db.collection.count) operation: [source]
The execution of this explain will *not* modify data but runs the query predicate of the update operation. For candidate plans, MongoDB returns the execution information captured during the [plan selection phase.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) [source]
- `SHARD_MERGE` for merging results from shards [source]
- `SHARDING_FILTER` for filtering out orphan documents from shards [source]
For unsharded collections, `explain` returns the following `executionStats` information: [source]
If a document is examined multiple times during query execution, [`explain.executionStats.totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalDocsExamined) counts each examination. That is, [`explain.executionStats.totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalDocsExamined) is *not* a count of the total number of *unique* documents examined. [source]
Starting in MongoDB 5.1, a stage can have these input stages: [source]
Each `inputStage` can have different fields depending on the value of `inputStage.stage`. The following table describes possible fields and what stages they can appear in. [source]
Third-party guides add numeric thresholds to the docsExamined/nReturned ratio: Netdata calls 1:1 ideal and above 100:1 severe inefficiency. These figures are blog rules of thumb; the MongoDB docs give no numeric cutoff. [source]
An efficient indexed query examines about as many keys and documents as it returns. In the MongoDB docs example, an index on year gives nReturned = totalKeysExamined = totalDocsExamined = 3809, which the docs call 'a very efficient query'. [source]
For more information on query plans, see [Explain Results.](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) [source]
The [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) method returns a document with the query plan and, optionally, the execution statistics. [source]
- The [`db.collection.find().explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) returns the `explain()` information on the query plan. [source]
Counts of the data access paths and index bounds that the winning plans use. A single winning plan can match multiple access path counters. [source]
Counts the data access paths and index bounds that each winning plan uses. The access path counters are not mutually exclusive, so one query execution can increment several of them. [source]
A string that specifies whether the cursor uses a collection scan (`COLLSCAN`) or an index scan (`IXSCAN { ... }`). [source]
| Access Path | Counters | | --- | --- | | Collection scan | `collscan`; `collscanProject`; `collscanProjectSort`; `collscanProjectSortProject`; `collscanSort`; `collscanSortProject`; `collscanSortProjectSort` | | Index scan with a fetch | `ixscanFetch`; `ixscanFetchProject`; `ixscanFetchProjectSort`; `ixscanFetchProjectSortProject`; `ixscanFetchSort`; `ixscanFetchSortProject`; `ixscanFetchSortProjectSort`; `ixscanFetchSortMerge`; `ixscanFetchSortMergeProject` | | Index scan with an `$or` | `ixscanFetchOr`; `ixscanFetchOrProject`; `ixscanFetchOrProjectSort`; `ixscanFetchOrSort`; `ixscanFetchOr [source]
This document appears if the query used the [slot-based execution query engine.](https://www.mongodb.com/docs/manual/reference/sbe.md#std-label-sbe-landing) [source]
- Docs Examined (`docsExamined`): Number of documents MongoDB inspected for the query. If Docs Examined is significantly larger than Docs Returned, this often means that: [source]
- [`executionStats.totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalDocsExamined) displays `21349` to indicate that MongoDB had to scan all 21,349 documents in the collection to find the 3,809 matching documents. [source]
- [`executionStats.totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.totalDocsExamined) display `3809` to indicate that MongoDB scanned 3,809 documents. [source]
executionStats.nReturned displays 3809 to indicate that the winning query plan returns 3,809 documents. [source]
| Parameter | Necessity | Type | Description | | --- | --- | --- | --- | | `verbose` | Optional | String | Determines the amount of information to include in the explain output. The possible verbosity modes are: `allPlansExecution`; `executionStats`; `queryPlanner` (*Default*) For backwards compatibility with earlier versions of `explain()`, MongoDB interprets `true` as `allPlansExecution` and `false` as `queryPlanner`. For more information on the modes, see [Verbosity Modes.](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#std-label-explain-cursor-method-verbosity) | [source]
If you run `cursor.explain()` against a database that does not exist on a sharded cluster, the execution stage reaches the end-of-stream and the operation does not create the database. For more information on end-of-stream execution stats, see [`explain.executionStats.executionStages.isEOF`.](https://www.mongodb.com/docs/manual/reference/explain-results.md#mongodb-data-explain.executionStats.executionStages.isEOF) [source]
The following example runs [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) in ["executionStats"](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#std-label-explain-method-executionStats) verbosity mode to return the query planning and execution information for the specified [`db.collection.find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find.md#mongodb-method-db.collection.find) operation: [source]
The following query uses the `options` parameter to get the `executionStats` explain output: [source]
Counts of the types of plan stages that appear in the winning plans. A single winning plan can match multiple node counters. [source]
Counts the types of plan stages that appear in each winning plan. The node counters are not mutually exclusive, so one query execution can increment several of them. [source]
You can view more verbose explain output by passing the `executionStats` or `allPlansExecution` explain modes to the [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) method. [source]
For more information on execution statistics of collection scans, see [Interpret Explain Plan Results.](https://www.mongodb.com/docs/manual/tutorial/analyze-query-plan.md) [source]
explain.queryPlanner.winningPlan.inputStage [source]
explain.queryPlanner.winningPlan.inputStages [source]
explain.queryPlanner.winningPlan.queryPlan.inputStage [source]
See explain.queryPlanner.winningPlan.inputStage. [source]
The returned explain.executionStats information details the execution of the winning plan. To include executionStats in the results, you must run the explain in either: [source]
allPlansExecution verbosity mode. Use allPlansExecution mode to include partial execution data captured during plan selection. [source]
For more information on execution statistics of collection scans, see Interpret Explain Plan Results. [source]
Query knobs set through query settings always appear, even if their value equals the default. However, explain output omits query knobs that you have not explicitly set. [source]
The default verbosity of `explain` and [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) differs. `explain` defaults to `allPlansExecution` while `db.collection.explain()` defaults to `queryPlanner`. [source]
Affects how thoroughly MongoDB indexes range values. Low sparsity (dense indexing) improves query performance, but stores more documents in the encrypted metadata collections for each insert or update operation, causing greater storage overhead. High sparsity does the opposite. [source]
).hint( { year: 1, rated: 1 } ).explain("executionStats") [source]
).hint( { rated: 1, year: 1 } ).explain("executionStats") [source]
The following example shows how MongoDB uses bounds intersection to define a smaller range of values to query, resulting in improved query performance. [source]
The following example shows how MongoDB uses compound bounds to define a more efficient query constraint, resulting in improved query performance. [source]
system.profile.keysExamined [source]
system.profile.docsExamined [source]
system.profile.execStats.inputStages [source]
"planSummary" : "IXSCAN { a: 1, _id: -1 }", [source]
You can also unsubscribe by clicking the unsubscribe link in any Query Shape Report email. The link directs you to Project Settings, where Atlas unsubscribes the project. The unsubscribe link works without requiring you to log in. [source]
Before MongoDB 7.0.22, 8.0.5, and 8.1.0, `planningTimeMicros` might include work that the command performs before a query retry, such as a sharding metadata refresh. Don't rely on this field alone to evaluate query-planning performance. To evaluate query-planning performance, review the total operation duration, [`keysExamined`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.keysExamined), [`docsExamined`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.docsExamined), and relevant sharding or lock-wa [source]
explain.executionStats.executionStages.inputStage [source]
Each stage passes its resulting documents or index keys to the parent node. The leaf nodes access the collection or the indices. The internal nodes use the documents or the index keys that result from the child nodes. The root node indicates the stage that MongoDB ultimately derives the result set from. [source]
- `EXPRESS` stages for a limited set of queries that can bypass regular query planning to use optimized index scan plans *(New in version 8.0.)* [source]
A document that describes the child stage, which provides the documents or index keys to its parent. The field is present *if* the parent stage has only one child. [source]
An array of documents describing the child stages. Child stages provide the documents or index keys to the parent stage. The field is present *if* the parent stage has multiple child nodes. For example, stages for [$or expressions](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-output-or-expression) might consume input from multiple sources. [source]
Each knob keeps the type, bounds, and default of its underlying server parameter, and `setQuerySettings` runs the same validation that [`setParameter`](https://www.mongodb.com/docs/manual/reference/command/setparameter.md#mongodb-dbcommand-dbcmd.setParameter) runs. `setQuerySettings` rejects the following values: [source]
In general, if keysExamined is much higher than nreturned, the database is scanning many index keys to find the result documents. Consider creating or adjusting indexes to improve query performance.. [source]
- Bounded clustered collection scans that specify `min` and `max` record bounds [source]
In previous versions of MongoDB, `cursor.explain()` returned the `clauses` array that detailed the indexes. [source]
2. Create a multikey index [source]
- The bounds for the greater than or equal to 90 predicate (`$gte: 90`) are `[ [ 90, Infinity ] ]`. [source]
- The bounds for the less than or equal to 99 predicate (`$lte: 99`) are `[ [ -Infinity, 99 ] ]`. [source]
MongoDB makes no guarantee as to which of the two bounds it chooses. [source]
2. Create a compound multikey index [source]
The preceding query specifies a condition on both keys of the index (`item` and `ratings`). [source]
- The bounds for the `item: "XYZ"` predicate are `[ [ "XYZ", "XYZ" ]]`. [source]
- The bounds for the `ratings: { $gte: 3 }` predicate are `[ [ 3, Infinity ] ]`. [source]
- The bounds for the `item: "XYZ"` predicate are `[ [ "XYZ", "XYZ" ] ]`. [source]
- The bounds for the `score: { $lte: 5 }` predicate are `[ [ -Infinity, 5] ]`. [source]
- The bounds for the `by: "anon"` predicate are `[ "anon", "anon" ]`. [source]
- MongoDB compounds the `item` bounds with the `"ratings.score"` bounds: [source]
- MongoDB compounds the `item` bounds with the `"ratings.by"` bounds: [source]
- The index keys must share the same field path up to but excluding the field names. [source]
1. Create a compound multikey index [source]
- The bounds for the `score: { $lte: 5 }` predicate are `[ [ -Infinity, 5 ] ]`. [source]
- The bounds for the `by: "anon"` predicate are `[ [ "anon", "anon" ] ]`. [source]
If you use [`min()`](https://www.mongodb.com/docs/manual/reference/method/cursor.min.md#mongodb-method-cursor.min) with [`max()`](https://www.mongodb.com/docs/manual/reference/method/cursor.max.md#mongodb-method-cursor.max) to specify a range: [source]
- the bound specified by [`max()`](https://www.mongodb.com/docs/manual/reference/method/cursor.max.md#mongodb-method-cursor.max) must be greater than the bound specified by [`min()`.](https://www.mongodb.com/docs/manual/reference/method/cursor.min.md#mongodb-method-cursor.min) [source]
A string that specifies the [namespace](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-namespace) with the names of the database and the collection accessed by the query. The namespace has the format `<database>.<collection>`. [source]
Starting in MongoDB 8.0, if a query uses [block processing](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-querying.md#std-label-timeseries-querying-block-processing), `block_to_row` and `ts_bucket_to_cellblock` appear in the `stages` output. [source]
The explain execution statistics provide the peak memory for the entire query and also for each blocking stage. If there is only one blocking stage, the query and stage `peakTrackedMemBytes` values are the same. [source]
MongoDB 8.2 removes `profileOperationResourceConsumptionMetrics`. Therefore, code depending on [operationMetrics](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-executionStats) does not work. [source]
| Name | Notes | | --- | --- | | [MongoDB Cloud Manager](https://www.mongodb.com/products/tools/cloud-manager) | MongoDB Cloud Manager is a cloud-based suite of services for managing MongoDB deployments. MongoDB Cloud Manager provides monitoring, backup, and automation functionality. For an on-premises solution, see also [Ops Manager, available in MongoDB Enterprise Advanced.](https://www.mongodb.com/products/mongodb-enterprise-advanced) | | [VividCortex](https://www.vividcortex.com/) | VividCortex provides deep insights into MongoDB [production database workload and query performance](https:/ [source]
The `IXSCAN` also includes the specification document of the index used. [source]
For write operations, keysExamined and docsExamined include reads performed during write conflict retries. If an update encounters write conflicts and retries, MongoDB re-reads the index keys and documents on each attempt. As a result, these values can exceed the number of documents matched or modified by the operation. [source]
If $in has fewer than 201 array elements, the elements are expanded and then merged in the sort order specified for the index using a SORT_MERGE stage. This improves performance for small arrays. In this case, $in is similar to an equality predicate with ESR. [source]
executionStats.totalKeysExamined displays 0 to indicate that this query is not using an index. [source]
MongoDB scanned 246 index keys (executionStats.totalKeysExamined) to return 235 matching documents (executionStats.nReturned). [source]
The `trimFactor` controls the throughput of concurrent inserts and updates. A higher `trimFactor` increases the throughput of concurrent insert and updates at the cost of slowing down some range read operations. A lower `trimFactor` does the opposite. [source]
For more thorough information on contention factor and its cryptographic implications, see "Section 9: Guidelines" in MongoDB's [Queryable Encryption Technical Paper](https://www.mongodb.com/resources/products/capabilities/queryable-encryption-technical-paper). [source]
- `timeField` values that are close together. The time series collection's `granularity`, `bucketMaxSpanSeconds`, and `bucketRoundingSeconds` parameters control the time span covered by each bucket. For more information, see [Set Granularity for Time Series Data.](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-granularity.md#std-label-timeseries-granularity) [source]
If a document with a time of `2023-03-27T16:24:35Z` does not fit an existing bucket, MongoDB creates a new bucket with a minimum time of `2023-03-27T16:00:00Z` and a maximum time of `2023-03-27T16:59:59Z`. [source]
You can modify a time series collection's granularity, but only to change from finer to coarser measurements, such as extending bucket coverage from minutes to hours. This doesn't change how data is stored across existing buckets. [source]
The following [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) command runs in `"queryPlanner"` verbosity mode to return the query planning information for a [`count`](https://www.mongodb.com/docs/manual/reference/command/count.md#mongodb-dbcommand-dbcmd.count) command: [source]
The indexes specified to indexNames must be the entire set of in-progress builds associated to a given index builder, i.e. the indexes built by a single createIndexes or db.collection.createIndexes() operation. [source]
The indexes specified to indexNames must be the entire set of in-progress builds associated to a given index builder, i.e. the createIndexes() operation. [source]
The indexNames field specifies the names of the indexes. Since the indexes were created without an explicit name, MongoDB generated an index name by concatenating the names of the indexed fields and the sort order. [source]
- Choose a field such as `_id` which generally changes in a consistent direction over time and has a [unique index](https://www.mongodb.com/docs/manual/core/index-unique.md#std-label-index-type-unique) to prevent duplicate values, [source]
Specifies the index's fields. For each field, specify a key-value pair in which the key is the name of the field to index and the value is either the index direction or index type. If specifying direction, specify 1 for ascending or -1 for descending. [source]
- To learn how MongoDB combines multikey index bounds to improve performance, see [Multikey Index Bounds.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/multikey-index-bounds.md#std-label-indexes-multikey-bounds) [source]
If an ascending or a descending index is on a single field, the sort operation on the field can be in either direction. [source]
For a query to use a compound index for a sort, the specified sort direction for all keys in the cursor.sort() document must match the index key pattern or match the inverse of the index key pattern. For example, an index key pattern { a: 1, b: -1 } can support a sort on { a: 1, b: -1 } and { a: -1, b: 1 } but not on { a: -1, b: -1 } or {a: 1, b: 1}. [source]
```javascript db.runCommand( { collMod: "apples", index: { keyPattern: { type: 1 }, prepareUnique: true } } ) ``` [source]
```javascript db.runCommand( { collMod: "apples", index: { keyPattern: { type: 1 }, unique: true }, dryRun: true } ) ``` [source]
```javascript db.runCommand( { collMod: "apples", index: { keyPattern: { type: 1 }, unique: true } } ) ``` [source]
db.pizzaOrders.explain().find( [source]
MongoDB combines bounds by either [intersecting](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/multikey-index-bounds.md#std-label-multikey-index-bounds-intersecting) or [compounding](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/multikey-index-bounds.md#std-label-multikey-index-bounds-compound) bounds. [source]
Given an indexed array field, consider a query that specifies multiple query predicates on the array and uses a [multikey index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md#std-label-index-type-multikey) to fulfill the query. MongoDB can intersect the multikey index bounds if an [`$elemMatch`](https://www.mongodb.com/docs/manual/reference/operator/query/elemmatch.md#mongodb-query-op.-elemMatch) operator joins the query predicates. [source]
For example, consider a compound index `{ temperature: 1, humidity: 1 }` with the following bounds: [source]
MongoDB compounds the bounds for the `item` key with either the bounds for `"ratings.score"` or the bounds for `"ratings.by"`, depending upon the query predicates and the index key values. MongoDB does not guarantee which bounds it compounds with the `item` field. [source]
For a field in an embedded document, the [dotted field name](https://www.mongodb.com/docs/manual/core/document.md#std-label-document-dot-notation), such as `"a.b.c.d"`, is the field path for `d`. To compound the bounds for index keys from the same array, the `$elemMatch` must be on the path up to *but excluding* the field name itself (meaning `"a.b.c"`). [source]
The following example shows how MongoDB combines bounds for index keys from the same array. This example uses the `survey2` collection used in the [previous example.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/multikey-index-bounds.md#std-label-index-bounds-example-non-array-multiple-array) [source]
In the top right of the aggregation pipeline builder, click the Explain button to open the Explain Plan modal. [source]
| Parameter | Type | Description | | --- | --- | --- | | `indexBounds` | document | The inclusive lower bound for the index keys. | [source]
- the index bounds specified in [`min()`](https://www.mongodb.com/docs/manual/reference/method/cursor.min.md#mongodb-method-cursor.min) and [`max()`](https://www.mongodb.com/docs/manual/reference/method/cursor.max.md#mongodb-method-cursor.max) must both refer to the keys of the same index. [source]
Indexes store entries in either ascending (`1`) or descending (`-1`) order. For [compound indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound.md#std-label-index-type-compound), sort order can determine whether the index can support a sort operation. The direction of a field in a compound index is relevant only if there is a sort on multiple fields in opposite directions. [source]
MongoDB can traverse a compound index in either direction. If the application allows users to view the leaderboard in reverse order, the index supports that query as well. [source]
| Name | Type | Required | Description | | --- | --- | --- | --- | | indexName | string | false | Name of the index. | [source]
On the Explain Plan modal, you can view the explain stages as a Visual Tree, where each query operation appears as a node on the tree. You can also view the explain details in raw JSON format by selecting the Raw Output view. [source]
For example, the following explain plan provides detailed information on a query that filters for `{ title : "Jurassic Park" }`: [source]
The default location bounds for 2d indexes allow latitudes less than -90 and greater than 90, which are invalid values. The behavior of geospatial queries with these invalid points is not defined. [source]
Explain plan results for queries are subject to change between MongoDB versions. [source]
You can see the optimized pipeline in the [explain plan.](https://www.mongodb.com/docs/manual/reference/method/db.collection.aggregate.md#std-label-example-aggregate-method-explain-option) [source]
You can see this optimized pipeline in the [explain plan.](https://www.mongodb.com/docs/manual/reference/method/db.collection.aggregate.md#std-label-example-aggregate-method-explain-option) [source]
The `explain()` method has the following form: [source]
The `explain()` method has the following parameter: [source]
The behavior of [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) and the amount of information returned depend on the `verbosity` mode. [source]
[`db.collection.explain().find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) is similar to [`db.collection.find().explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) with the following key differences: [source]
- The [`db.collection.explain().find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) construct allows for the additional chaining of query modifiers. For list of query modifiers, see [db.collection.explain().find().help().](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#std-label-explain-method-help) [source]
[`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) operations can return information regarding: [source]
- [`serverInfo`](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-serverInfo), which provides information on the MongoDB instance. [source]
For more examples, see [Examples](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#std-label-explain-method-examples). See also [db.collection.explain().help().](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#std-label-explain-method-help) [source]
The [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) method has the following parameter: [source]
For write operations, [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) returns information about the write operation that would be performed but does not actually modify the database. [source]
The [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) method wraps the [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) command and is the preferred way to run [`explain`.](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) [source]
[`db.collection.explain().aggregate()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) is equivalent to passing the [explain](https://www.mongodb.com/docs/manual/reference/method/db.collection.aggregate.md#std-label-example-aggregate-method-explain-option) option to the [`db.collection.aggregate()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.aggregate.md#mongodb-method-db.collection.aggregate) method. [source]
[`db.collection.explain().find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) returns a cursor, which allows for the chaining of query modifiers. To see the list of query modifiers supported by [`db.collection.explain().find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) as well as cursor-related methods, run: [source]
You can chain multiple modifiers to `db.collection.explain().find()`. For an example, see [Explain `find()` with Modifiers.](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#std-label-explain-find-modifiers) [source]
- To learn about multikey index bounds, see [Multikey Index Bounds.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/multikey-index-bounds.md#std-label-indexes-multikey-bounds) [source]
```javascript { cursor: { id: Long('0'), ns: 'test.$cmd.aggregate', firstBatch: [ { type: 'InconsistentIndex', description: 'Found an index of a sharded collection that is inconsistent between different shards', details: { namespace: 'test.reviews', info: { missingFromShards: [], inconsistentProperties: [ { k: 'expireAfterSeconds', v: Long('600') }, { k: 'expireAfterSeconds', v: 3600 } ], indexName: 'reviewDt_1' } } }, { type: 'InconsistentIndex', description: 'Found an index of a sharded collection that is inconsistent between different shards', details: { namespace: 'test.reviews', info: { m [source]
- The [cursor.explain()](https://www.mongodb.com/docs/manual/reference/method/cursor.explain/) command for [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) provides performance details for all queries. [source]
Index scans where a field has multiple bounds, counted separately by the number of bounds. boundsUnionedSmall counts fields with 2 to 50 bounds, and boundsUnionedLarge counts fields with 51 or more bounds. [source]
The following example uses [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) to view detailed information regarding the execution plan of the aggregation pipeline. [source]
**Note: The explain output is subject to change between releases.** [source]
This section shows the `explain` output for MongoDB 5.1 and later. To see the explain output for older versions of MongoDB, refer to the documentation for that version. [source]
The [explain results](https://www.mongodb.com/docs/manual/reference/explain-results.md#std-label-explain-results) can include execution statistics for queries that use a [`$lookup`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup.md#mongodb-pipeline-pipe.-lookup) pipeline stage. To include those execution statistics, you must run the explain operation in one of these execution verbosity modes: [source]
The following fields are included in the explain results for a [`$lookup`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup.md#mongodb-pipeline-pipe.-lookup) query: [source]
Unique integer field that identifies each stage in the execution plan. Field is included in all stages throughout the explain results. [source]
The explain results can include execution statistics for queries that use a $lookup pipeline stage. To include those execution statistics, you must run the explain operation in one of these execution verbosity modes: [source]
The explain results includes execution statistics for queries that use a $search, $searchMeta, or $vectorSearch pipeline stage. To include execution statistics for search queries, run the explain command in one of the following execution verbosity modes: [source]
Starting in MongoDB 8.0, explain outputs the following field: [source]
Starting in MongoDB 9.0, explain outputs the following field: [source]
The cursor.explain() command for mongosh provides performance details for all queries. [source]
In [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#std-program-mongosh), this command can also be run through the [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain.md#mongodb-method-db.collection.explain) and [`cursor.explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md#mongodb-method-cursor.explain) helper methods. [source]
- The indexes specified to `indexNames` must be the entire set of in-progress builds associated to a given index builder, i.e. the [`createIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindexes.md#mongodb-method-db.collection.createIndexes) operation. [source]
| Product Name | Minimum Version | Supports Queryable Encryption with Automatic Encryption | Supports Queryable Encryption with Explicit Encryption | | --- | --- | --- | --- | | MongoDB Atlas | 7.0 | Yes | Yes | | MongoDB Enterprise Advanced | 7.0 | Yes | Yes | | MongoDB Community Edition | 7.0 | No | Yes | [source]
| Product Name | Minimum Version | Supports CSFLE with Automatic Encryption | Supports CSFLE with Explicit Encryption | | --- | --- | --- | --- | | MongoDB Atlas | [All supported MongoDB versions](https://www.mongodb.com/docs/atlas/reference/faq/database/#which-versions-of-mongodb-do-service-clusters-use-) | Yes | Yes | | MongoDB Enterprise Advanced | 4.2 | Yes | Yes | | MongoDB Community Edition | 4.2 | No | Yes | [source]
These parameters are intended for advanced users only. The default values are suitable for the majority of use cases, and should only be modified if your use case requires it. [source]
Only appears if usedDisk is true. [source]
Don't rely on this field alone to evaluate query-planning performance. Review the total operation duration, keysExamined, docsExamined, and relevant sharding or lock-wait metrics. [source]
"executionTimeMillisEstimate" : 0, [source]
"executionTimeMillisEstimate" : 103771, [source]
2. Add a sort stage to sort by order date. [source]
4. Add a sort stage to sort by first order date. [source]
2) Add a sort stage to sort by order date. [source]
4) Add a sort stage to sort by first order date. [source]
The maximum amount by which the current cluster time can be advanced; specifically, [`maxAcceptableLogicalClockDriftSecs`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.maxAcceptableLogicalClockDriftSecs) is the maximum difference between the new value of the cluster time and the current cluster time. Cluster time is a logical time used for ordering of operations. [source]
On this page, you can learn about the security benefits of Queryable Encryption, how it works, and how it compares to other security mechanisms supported by MongoDB. You can also view a fictional scenario that demonstrates the value of Queryable Encryption in securing your data. [source]
| Threat | TLS/SSL Transport Encryption | Encryption at Rest (EaR) | Queryable Encryption + TLS/SSL + EaR | CSFLE + TLS/SSL + EaR | | --- | --- | --- | --- | --- | | Network Snooping (attacker has access to network traffic) | Reveals [operation metadata](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-operation-metadata) | Reveals operation metadata | Reveals operation metadata | Reveals operation metadata | | Database Recoveries from Disk (attacker has physical disk access) | Reveals database | Reveals *size of database* and operation metadata | Reveals *size of database* a [source]
).explain("executionStats") [source]
totalDocsExamined: 21349, [source]
executionStats.totalDocsExamined display 3809 to indicate that MongoDB scanned 3,809 documents. [source]
All metrics in this document are reported on both [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) and [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos). On [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos), the `docsExamined` and `bytesRead` counters are aggregated from the shards that serve the change stream. The remaining metrics aren't aggregated from shards and count only the change stream cursors that the [`mongos`](https://www.mongo [source]
A document that holds counters related to sort stages. [source]
The total number of writes to disk caused by sort stages. [source]
Aggregates the total number of "works" performed in the classic multiplanner. [source]
A histogram measuring the number of "works" performed during an invocation of the classic multiplanner. [source]
- The sync source's majority commit point has advanced since the last batch sent to this secondary. [source]
| Mode | Description | | --- | --- | | `AES256-CBC` | 256-bit Advanced Encryption Standard in Cipher Block Chaining Mode | | `AES256-GCM` | 256-bit Advanced Encryption Standard in Galois/Counter Mode Available only on Linux. MongoDB Enterprise on Windows no longer supports `AES256-GCM` as a block cipher for encryption at rest. This usage is only supported on Linux. | [source]
Available tabs: other tabs: queryplanner, executionstats, allplans --> [source]
- run the explain in `executionStats` mode or `allPlansExecution` mode but without the [`$out`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/out.md#mongodb-pipeline-pipe.-out) stage to return information for the stages that precede the [`$out`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/out.md#mongodb-pipeline-pipe.-out) stage. [source]
- MongoDB Ops Manager is [an on-premises solution available in MongoDB Enterprise Advanced](https://www.mongodb.com/products/mongodb-enterprise-advanced) that monitors running MongoDB deployments to collect data and provide visualization and alerts based on that data. [source]
- Use [MongoDB Cloud Manager](https://www.mongodb.com/products/tools/cloud-manager) or [Ops Manager, an on-premise solution available in MongoDB Enterprise Advanced](https://www.mongodb.com/products/mongodb-enterprise-advanced) or another monitoring system to monitor key database metrics and set up alerts for them. Include alerts for the following metrics: [source]
Fetch stages, counted separately based on whether the stage applies a filter. [source]
usedDisk: {true: Long("0"), false: Long("1")}, [source]
```python find_payload = client_encryption.encrypt( patientId, Algorithm.INDEXED, data_key_id_1, query_type=QueryType.EQUALITY, contention_factor=8, ) doc = coll.find_one({"encryptedIndexed": find_payload}) print("\nReturned document:\n") pprint.pprint(doc) ``` [source]
If the query bar is empty, you can click the filter bar to open the query autocomplete menu and view up to 50 recent or favorite queries. To scroll through your most recent queries, you can use the up ↑ and down ↓ arrow keys. If a query is highlighted on the menu, it displays a pop-up panel that shows the filter, project, and sort stages of the query. To select a query from the autocomplete menu, press Enter, press Tab, or click the query. [source]
2) Add a sort stage to sort from youngest to oldest. [source]
2. Add a sort stage to sort from youngest to oldest. [source]
<executionPart>SpilledRecords indicates the number of records written to temporary files on disk. [source]
For more information on how sharding works with aggregations, read the sharding chapter in the Practical MongoDB Aggregations e-book. [source]
executionTimeMillis: <int>, [source]
totalKeysExamined: <int>, [source]
totalDocsExamined: <int>, [source]
executionTimeMillisEstimate: <int>, [source]
spilledRecords: <long long>, [source]
explain.executionStats.nReturned [source]
explain.executionStats.executionTimeMillis [source]
explain.executionStats.peakTrackedMemBytes [source]
explain.executionStats.totalKeysExamined [source]
explain.executionStats.totalDocsExamined [source]
explain.executionStats.score [source]
explain.executionStats.executionStages [source]
explain.executionStats.executionStages.executionTimeMillisEstimate [source]
explain.executionStats.executionStages.opens [source]
explain.executionStats.executionStages.closes [source]
explain.executionStats.executionStages.works [source]
explain.executionStats.executionStages.saveState [source]
explain.executionStats.executionStages.restoreState [source]
explain.executionStats.executionStages.isEOF [source]
explain.executionStats.executionStages.opType [source]
explain.executionStats.executionStages.bucketFilter [source]
explain.executionStats.executionStages.residualFilter [source]
explain.executionStats.executionStages.nBucketsUnpacked [source]
explain.executionStats.executionStages.nMeasurementsDeleted [source]
explain.executionStats.executionStages.nMeasurementsInserted [source]
explain.executionStats.executionStages.nMeasurementsMatched [source]
explain.executionStats.executionStages.nMeasurementsModified [source]
explain.executionStats.executionStages.nMeasurementsUpserted [source]
Starting in MongoDB 9.0, the COUNT_SCAN, GEO_NEAR_2D, GEO_NEAR_2DSPHERE, and UPDATE stages also report this field. [source]
COUNT_SCAN, GEO_NEAR_2D, GEO_NEAR_2DSPHERE, GROUP, SORT, UPDATE [source]
explain.executionStats.allPlansExecution [source]
explain.executionStats.operationMetrics [source]
totalDocsExamined: <long>, [source]
totalKeysExamined: <long>, [source]
executionTimeMillisEstimate: <long> [source]
explain.totalDocsExamined [source]
explain.totalKeysExamined [source]
explain.executionTimeMillisEstimate [source]
docsExamined: 10000 cursorExhausted:1 numYields:234 [source]
For more information on how sharding works with [aggregations](https://www.mongodb.com/docs/manual/core/aggregation-pipeline.md#std-label-aggregation-pipeline), read the sharding chapter in the [Practical MongoDB Aggregations](https://www.practical-mongodb-aggregations.com/guides/sharding.html) e-book. [source]
The following [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) operation runs in `"executionStats"` verbosity mode to return the query planning and execution information for a [`count`](https://www.mongodb.com/docs/manual/reference/command/count.md#mongodb-dbcommand-dbcmd.count) command: [source]
indexNames: [ <document> ], [source]
"indexNames" : ["invoices_1", "fullfillmentStatus_1"], [source]
- [`$densify`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/densify.md#mongodb-pipeline-pipe.-densify) does not filter out documents with [field](https://www.mongodb.com/docs/manual/reference/operator/aggregation/densify.md#std-label-densify-field) values outside of the specified bounds. [source]
Starting in MongoDB 8.0, [`$densify`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/densify.md#mongodb-pipeline-pipe.-densify) treats bounds with an equal lower and upper bound as an empty set and does not generate a document with the bound as the field value. [source]
For example, a [range.bounds](https://www.mongodb.com/docs/manual/reference/operator/aggregation/densify.md#std-label-densify-bounds) of `[10, 10]` generates an extra document with field value `10` in versions prior to 8.0, but does not generate such a document in 8.0 and later. [source]
- `bounds: [ ISODate("2021-05-18T00:00:00.000Z"), ISODate("2021-05-18T08:00:00.000Z") ]` sets the range of time that is densified. [source]
- For encrypted fields with range queries enabled, review the field configuration, especially the [min, max,](https://www.mongodb.com/docs/manual/core/queryable-encryption/fundamentals/encrypt-and-query.md#std-label-qe-field-min-max) and [precision](https://www.mongodb.com/docs/manual/core/queryable-encryption/fundamentals/encrypt-and-query.md#std-label-qe-field-precision) parameters. Setting tight bounds for range queries greatly decreases the performance impact of those fields. [source]
- Time has moved forward or backward past the covered time span, as indicated by an incoming document timestamp that falls outside of the bucket's bounds. These bounds are determined by the collection's [granularity](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-granularity.md#std-label-timeseries-granularity) setting. [source]
Follow the directions on the [.NET/C# Driver Get Started](https://www.mongodb.com/docs/drivers/csharp/current/get-started/) page to create a new project and install driver dependencies. [source]
Follow the directions on the [Java Sync Driver Get Started](https://www.mongodb.com/docs/drivers/java/sync/current/get-started/) page to create a new project and install driver dependencies. [source]
Follow the directions on the [Node.js Get Started](https://www.mongodb.com/docs/drivers/node/current/get-started/) page to create a new project directory and install driver dependencies. [source]
Follow the directions on the [PyMongo Get Started](https://www.mongodb.com/docs/languages/python/pymongo-driver/current/get-started/) page to create a new project directory and install driver dependencies. [source]
```json { "ts" : { "$date" : "1984-03-05T13:00:00Z" }, "metaData" : { "callLetters" : "VCSZ", "elevation" : 9999, "position" : { "coordinates" : [ -47.9, 47.6 ], "type" : "Point" }, "qualityControlProcess" : "V020", "st" : "x+47600-047900", "type" : "FM-13" }, "dewPoint" : { "value" : 999.9, "quality" : "9" }, "wind" : { "direction" : { "angle" : 999, "quality" : "9" }, "type" : "9", "speed" : { "rate" : 999.9, "quality" : "9" } }, "skyCondition" : { "ceilingHeight" : { "value" : 99999, "quality" : "9", "determination" : "9" }, "cavok" : "N" }, "dataSource" : "4", "pressure" : { "value" : 1015 [source]
```text { "_id": {"$oid": "<object-id>"}, "ts": {"$date": "1984-03-05T13:00:00Z"}, "metaData": { "st": "x+47600-047900", "position": {"type": "Point", "coordinates": [-47.9, 47.6]}, "elevation": 9999, "callLetters": "VCSZ", "qualityControlProcess": "V020", "type": "FM-13" }, "dataSource": "4", "airTemperature": {"value": -3.1, "quality": "1"}, "dewPoint": {"value": 999.9, "quality": "9"}, "pressure": {"value": 1015.3, "quality": "1"}, "wind": { "direction": {"angle": 999, "quality": "9"}, "type": "9", "speed": {"rate": 999.9, "quality": "9"} }, "visibility": { "distance": {"value" [source]
```shell { _id: ObjectId("<object-id>"), ts: ISODate("1984-03-05T13:00:00Z"), metaData: { st: "x+47600-047900", position: { type: "Point", coordinates: [ -47.9, 47.6 ] }, elevation: 9999, callLetters: "VCSZ", qualityControlProcess: "V020", type: "FM-13" }, dataSource: "4", airTemperature: { value: -3.1, quality: "1" }, dewPoint: { value: 999.9, quality: "9" }, pressure: { value: 1015.3, quality: "1" }, wind: { direction: { angle: 999, quality: "9" }, type: "9", speed: { rate: 999.9, quality: "9" } }, visibility: { distance: { value: 999999, quality: "9" }, variability: { value: "N [source]
```text { _id: new ObjectId('<object-id>'), ts: 1984-03-05T13:00:00.000Z, metaData: { st: 'x+47600-047900', position: { type: 'Point', coordinates: [ -47.9, 47.6 ] }, elevation: 9999, callLetters: 'VCSZ', qualityControlProcess: 'V020', type: 'FM-13' }, dataSource: '4', airTemperature: { value: -3.1, quality: '1' }, dewPoint: { value: 999.9, quality: '9' }, pressure: { value: 1015.3, quality: '1' }, wind: { direction: { angle: 999, quality: '9' }, type: '9', speed: { rate: 999.9, quality: '9' } }, visibility: { distance: { value: 999999, quality: '9' }, variability: { value: 'N', q [source]
```text {'_id': ObjectId('<object-id>'), 'ts': datetime.datetime(1984, 3, 5, 13, 0), 'metaData': {'st': 'x+47600-047900', 'position': {'type': 'Point', 'coordinates': [-47.9, 47.6]}, 'elevation': 9999, 'callLetters': 'VCSZ', 'qualityControlProcess': 'V020', 'type': 'FM-13'}, 'dataSource': '4', 'airTemperature': {'value': -3.1, 'quality': '1'}, 'dewPoint': {'value': 999.9, 'quality': '9'}, 'pressure': {'value': 1015.3, 'quality': '1'}, 'wind': {'direction': {'angle': 999, 'quality': '9'}, 'type': '9', 'speed': {'rate': 999.9, 'quality': '9'}}, 'visibility': {'distance': {'value': 9 [source]
"keyPattern": <keyPattern>, [source]
"keyPattern": { "lastModifiedDate": 1 }, [source]
```javascript db.temporarytimeseries.findOne() { "_id" : ObjectId("<object-id>"), "ts" : ISODate("1984-03-05T13:00:00Z"), "dataSource" : "4", "airTemperature" : { "value" : -3.1, "quality" : "1" }, "dewPoint" : { "value" : 999.9, "quality" : "9" }, "pressure" : { "value" : 1015.3, "quality" : "1" }, "wind" : { "direction" : { "angle" : 999, "quality" : "9" }, "type" : "9", "speed" : { "rate" : 999.9, "quality" : "9" } }, "visibility" : { "distance" : { "value" : 999999, "quality" : "9" }, "variability" : { "value" : "N", "quality" : "9" } }, "skyCondition" : { "ceilingHeight" : { [source]
If the array elements are documents, you can sort by a document field. Specify the field name and a sort direction, ascending (`1`), or descending (`-1` ). [source]
Returns the cosine similarity between two numeric vectors represented as arrays or `binData` values. Cosine similarity measures the cosine of the angle between two vectors and indicates how similar their directions are, independent of their magnitudes. [source]
- `1` indicates the vectors point in identical directions. [source]
- `-1` indicates the vectors point in opposite directions. [source]
The `indexBounds` parameter has the following prototype form: [source]
Specifies a polygon for a [geospatial](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-geospatial) [`$geoWithin`](https://www.mongodb.com/docs/manual/reference/operator/query/geowithin.md#mongodb-query-op.-geoWithin) query on legacy coordinate pairs. The query returns pairs that are within the bounds of the polygon. The operator does *not* query for GeoJSON objects. [source]
The `min` and `max` bounds are **inclusive** and apply to both longitude and latitude. [source]
The [`$center`](https://www.mongodb.com/docs/manual/reference/operator/query/center.md#mongodb-query-op.-center) operator specifies a circle for a [`$geoWithin`](https://www.mongodb.com/docs/manual/reference/operator/query/geowithin.md#mongodb-query-op.-geoWithin) query. The query returns legacy coordinate pairs that are within the bounds of the circle. The operator does *not* return GeoJSON objects. [source]
Defines a circle for a [geospatial](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-geospatial) query that uses spherical geometry. The query returns documents that are within the bounds of the circle. You can use the [`$centerSphere`](https://www.mongodb.com/docs/manual/reference/operator/query/centersphere.md#mongodb-query-op.-centerSphere) operator on both [GeoJSON](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-GeoJSON) objects and legacy coordinate pairs. [source]
- An `_id` object that specifies the bounds of the bucket. [source]
Time has moved forward or backward past the covered time span, as indicated by an incoming document timestamp that falls outside of the bucket's bounds. These bounds are determined by the collection's granularity setting. [source]
- If `idx` exceeds the array bounds, [`$arrayElemAt`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/arrayelemat.md#mongodb-expression-exp.-arrayElemAt) does not return a result. [source]

Related concepts

executionStats — is a part of MongoDB explain output and plan stages
index — is a hypernym of MongoDB explain output and plan stages
index bounds — is a related of MongoDB explain output and plan stages
plan stage — is a part of MongoDB explain output and plan stages
query planner — is a synonym of MongoDB explain output and plan stages
database profiler — is a part of MongoDB explain output and plan stages
query shape — is a part of MongoDB explain output and plan stages
plan cache — is a part of MongoDB explain output and plan stages
query optimization — is a hypernym of MongoDB explain output and plan stages
hint — is a part of MongoDB explain output and plan stages
query settings — is a part of MongoDB explain output and plan stages
slot-based execution engine — is a related of MongoDB explain output and plan stages
index effectiveness — is a measure of MongoDB explain output and plan stages
$currentOp — is a related of MongoDB explain output and plan stages
$indexStats — is a part of MongoDB explain output and plan stages

Children

No children recorded.

← the whole tree · 3D view· how to read this page