MongoDB Explain Plans, Query Planner and Plan Cache

Parent: MongoDB Performance Troubleshooting · Published reference · snapshot 2026-10-19 · skill mongodb-expert/references/mongodb-explain-plans-and-query-planner.md

Also known as: Explain Plan Interpretation, Index Analysis, Index Analysis with $indexStats and Unused-Index Detection, Index Effectiveness Measurement, Query Planning and Plan Cache, Query Settings and Persistent Index Hints (8.0), Query Shapes and Query Hash and $queryStats, Slow Query Monitoring, Slow Query Monitoring (profiler and slow-query log and planSummary), explain-executionStats-usedDisk, hint() and Index Forcing

↓ Facts as markdown all context files

MongoDB explain output (queryPlanner, executionStats, allPlansExecution) details the plan the query optimizer selected and how it ran; the plan cache, query shapes with $queryStats, query settings and hint() steer or bypass that choice, and the database profiler, the slow query log and $indexStats measure what indexes actually did. Compiled from MongoDB manual, Atlas and Compass pages plus the run's verified claims; facets cover definitions, mechanisms, how-tos, problems and version changes.

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]
`planCacheKey` is a hash of the [plan cache query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape), further distinguished by any available indexes for the shape. [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]
A query shape hash is a string that uniquely identifies the query shape. An example query shape hash is `"F42757F1AEB68B4C5A6DE6182B29B01947C829C926BCC01226BDA4DDE799766C"`. [source]
- A high Docs Examined : Returned Ratio means the query is scanning many documents to return few results, which can be a sign of an inefficient query or missing indexes. [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]
In the classic multi-planner, the winning plan is the query plan that produces the most results during the trial period while performing the least amount of work. [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]
Query selectivity refers to how well the query predicate filters out documents in a collection. Query selectivity determines whether queries can use indexes effectively. [source]
explainVersion is the output format version for the plan, such as "1" or "2". [source]
- Knobs that are not marked as settable through query settings [source]
`queryShapeHash` is a hexadecimal string with the hash of a [query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-shape). For details, see [Query Shapes.](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) [source]
- Query Shape Reports are not available through the Atlas Administration API. [source]
- `slowms` is the **previous** [slowms](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-options-slowms) setting. [source]
- `sampleRate` is the **previous** [sampleRate](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-options-sampleRate) setting. [source]
- `filter` is the **previous** [filter](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-options-filter) setting. [source]
This parameter is not configurable with query settings. [source]
A query shape is a set of specifications that group similar queries together. Specifications can include filters, sorts, projections, aggregation pipeline stages, a namespace, and others. Queries that have similar specifications have the same query shape. [source]
The following is an excerpt from the [`system.profile`:](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) [source]
$queryStats groups queries with common properties into the same output document. The resulting document is called a query stats entry. [source]
- `$planCacheStats` is not allowed in: [source]
$indexStats is not allowed in transactions. [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]
The settings document accepts indexHints, queryFramework (classic or sbe), reject, comment (8.0.4 and 8.1+), and in 9.0 queryKnobs (per-shape server parameter overrides, merged not replaced) and maxTimeMS (takes precedence over command-level maxTimeMS). Query knobs are part of the plan cache key; an FCV downgrade from 9.0 removes knobs and they are not restored on re-upgrade. [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]
Index filters are set with the [`planCacheSetFilter`](https://www.mongodb.com/docs/manual/reference/command/plancachesetfilter.md#mongodb-dbcommand-dbcmd.planCacheSetFilter) command and determine which indexes the planner evaluates for a [query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-shape). A plan cache query shape consists of a combination of query, sort, and projection specifications. If an index filter exists for a given query shape, the planner only considers those indexes specified in the filter. [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]
If an index filter exists for the query shape, MongoDB ignores hint(). Cluster query settings also take precedence: index hints in command fields are ignored if a matching query setting already contains index hints. Index hints do not affect 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]
The [`dropIndexes`](https://www.mongodb.com/docs/manual/reference/command/dropindexes.md#mongodb-dbcommand-dbcmd.dropIndexes) operation only kills queries that are using the index being dropped. This may include queries considering the index as part of [query planning.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) [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]
- Cluster query settings take precedence over query settings or index hints passed as a command field. MongoDB ignores index hints in command fields if a matching query setting already contains index hints. [source]
Changing any shape component (e.g. the sort field from totalNumber to price) yields a different queryShapeHash and planCacheShapeHash; changing only literal values (dates) does not. [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]
Starting in MongoDB 8.0, the pre-existing query shape is renamed to the plan cache query shape, and the queryHash field is renamed planCacheShapeHash. For the components of a command that differentiate plan cache query shapes, see the plan cache query shape definition. MongoDB 8.0 uses the new query shape and the existing plan cache query shape as shown on this page. [source]
the overall structure of the find, aggregation, and distinct commands, which support a wider range of query shapes than the existing plan cache query shape. [source]
- the overall structure of the `find`, `aggregation`, and `distinct` commands, which support a wider range of query shapes than the existing plan cache query shape. [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]
Hinting a partial index limits results to documents matching its filter expression; the index becomes part of the query's semantics. [source]
Contains information on the selection of the query plan by the query optimizer. [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]
- If `hasSort` is set to `true`, this indicates that the query contains a [`sort()`](https://www.mongodb.com/docs/manual/reference/method/cursor.sort.md#mongodb-method-cursor.sort) method. Unindexed [`sort()`](https://www.mongodb.com/docs/manual/reference/method/cursor.sort.md#mongodb-method-cursor.sort) methods can be very resource intensive. Check your search index configuration and confirm whether it supports the [`sort()`](https://www.mongodb.com/docs/manual/reference/method/cursor.sort.md#mongodb-method-cursor.sort) method. [source]
Optional. A flag that determines whether the index is hidden from the query planner. A hidden index is not evaluated as part of query plan selection. [source]
Hides an existing index from the query planner. An index hidden from the query planner is not evaluated as part of query plan selection. [source]
The number of queries that contain the `_id` field. For these queries, MongoDB uses the default index on the `_id` field and skips all query plan analysis. [source]
Hides an existing index from the query planner. An [index hidden from the query planner](https://www.mongodb.com/docs/manual/core/index-hidden.md#std-label-index-type-hidden) is not evaluated as part of query plan selection. [source]
If you count the number of documents in the `movies` collection and include a hint that specifies that sparse index, the operation returns only the documents that contain the `rated` field. [source]
2. Before creating the index, validate that no documents in the collection violate the index constraints. If a collection is distributed across shards and a shard contains a chunk with duplicate documents, the create index operation may succeed on the shards without duplicates but not on the shard with duplicates. To avoid leaving inconsistent indexes across shards, you can issue the [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) from a [`mongos`](https://www.mongodb.com/docs/manual/reference [source]
The [Query Profiler](https://www.mongodb.com/docs/atlas/tutorial/query-profiler.md#std-label-query-profiler) contains several metrics you can use to pinpoint specific inefficient queries. You can visualize up to the past 24 hours of query operations. The Query Profiler can show the Examined : Returned Ratio (index keys examined to documents returned) of logged queries, which might help you identify the queries that triggered a [`Query Targeting: Scanned / Returned`](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#mongodb-alert-Query-Targeting--Scanned---Returned) alert. The ch [source]
The `orders` collection contains the following index filters: [source]
The array of documents that contain the index filter information. [source]
The Query Profiler contains several metrics you can use to pinpoint specific inefficient queries. You can visualize up to the past 24 hours of query operations. The Query Profiler can show the Examined : Returned Ratio (index keys examined to documents returned) of logged queries, which might help you identify the queries that triggered a Query Targeting: Scanned / Returned alert. The chart shows the number of index keys examined to fulfill a query relative to the actual number of returned documents. [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]
Contains metrics related to CBR when it is used during query planning. CBR evaluates multiple query plans and selects the most efficient plan based on estimated costs. [source]
Messages related to queries, including query planner activities. To specify the log level for QUERY components, set the systemLog.component.query.verbosity parameter. [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]
Messages related to queries, including query planner activities. To specify the log level for [`QUERY`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-QUERY) components, set the [`systemLog.component.query.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.query.verbosity) parameter. [source]
When you downgrade the FCV from `9.0` to an earlier version, a migration updates the stored query settings. The migration removes every knob whose minimum FCV exceeds the target version and deletes any settings entry that still contains only default values. Re-upgrading to `9.0` does not restore the removed knobs. You must re-apply them with `setQuerySettings`. [source]
An array that contains statistics for the operations that are the input stages of the current stage. [source]
Query shapes exposing field names but redacted values may contain user PII (Personally Identifiable Information). To view truncated or full query shapes in Query Shape Insights, you must have one of the project roles listed above, which each give access to view PII (Personally Identifiable Information). For users without these permissions, Query Shape Insights identifies query shapes by their query shape hash. [source]
The Query Shape Insights table contains one row for each top query shape in your project, where top query shapes are determined by highest total execution time. Each row contains the query shape or its query shape hash, the namespace of the query shape, the query command, and any metrics that you select to display. You can use the Edit Columns button to choose which of the following metrics to include as table columns: [source]
You can also display charts for one or more of the metrics above by selecting each metric that you want to chart from the drop-down menu in the Query Shape Statistics component header. [source]
The total number queries that performed a collection scan. The total consists of queries that did and did not use a [tailable cursor.](https://www.mongodb.com/docs/manual/core/tailable-cursors.md#std-label-tailable-cursors-landing-page) [source]
Field values. $queryStats normalizes field values in a query to their data types (such as number or string) when the query is recorded. $queryStats never stores field values that contain user data. [source]
$queryStats returns an array of query stats entries. Some query stats entry properties contain literal values, and some properties are normalized to group common queries. [source]
MongoDB 9.0 updates the $queryStats output structure to improve metrics organization. [source]
The UTC time when $queryStats read this entry from the $queryStats virtual collection. asOf does not necessarily return the same UTC time for each result. Internally, the data structure is partitioned, and each partition will be read at an individual point in time. [source]
Contains aggregated runtime metrics associated with each query stats entry. Each query stats entry records statistics for each query that shares the same key. [source]
Contains the query shape and additional query attributes that group a set of queries together [source]
Contains attributes used to group similar queries together. For more information, see Query Shape. [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]
MongoDB omits counters with a count of zero and omits subdocuments that contain no counters. If none of the recorded queries produced plan shape counters, MongoDB omits the planShapeCounters document entirely. For example, a query that matches a single document by _id uses a fast path that doesn't match any tracked plan shape, so its query stats entry contains no planShapeCounters document. [source]
The key.queryShape document contains query shape fields. To learn about query shapes, see Query Shapes. [source]
Query stats entries may contain a metrics.supplementalMetrics document that provides additional information about your queries. [source]
| Document | Description | | --- | --- | | `key` | The unique combination of attributes that define an entry in the query stats output. The `key` contains attributes such as: [Query shape](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes); Client information; Read concern; [Collection type](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#std-label-queryStats-collectionType) Each unique combination of attributes creates a separate entry in the `$queryStats` virtual collection. | | `asOf` | The UTC time when `$queryStats` read this [source]
The `key.queryShape` document contains query shape fields. To learn about query shapes, see [Query Shapes.](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) [source]
When MongoDB logs `$queryStats` output, the results are redacted and anonymized. `$queryStats` output does not contain literals or field values. [source]
Messages related to $queryStats operations. To specify the log level for QUERYSTATS components, set the systemLog.component.queryStats.verbosity parameter. [source]
If a command with a specific query shape is rejected, MongoDB logs a message that states the query command was rejected. The message contains the query namespace, queryShapeHash, and the command with the rejected query. MongoDB only logs the message if the log verbosity level is set to at least 2. [source]
Messages related to [`$queryStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#mongodb-pipeline-pipe.-queryStats) operations. To specify the log level for `QUERYSTATS` components, set the [`systemLog.component.queryStats.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.queryStats.verbosity) parameter. [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]
- When an [index filter](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters) exists for the query shape, MongoDB ignores the [`hint()`.](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) [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]
planSummary alone does not show whether planning was expensive. Profiler entries carry fromMultiPlanner (true only when multiple candidate plans were evaluated) and replanned (true only when a cached plan was evicted and re-evaluated); both are omitted when false, e.g. for plan-cache hits. [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]
Because index filters override the expected behavior of the planner as well as the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) method, use index filters sparingly. [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]
Classic caching keys on a broadly parameterized query shape and stores only the index choice. SBE caching keys on a more conservative shape and stores a full SBE plan. SBE does not parameterize arrays, so find({a:'foo',b:[1]}) and find({a:'bar',b:[2]}) share a classic key but not an SBE key, and each new array value causes a miss and another multi-plan. SERVER-89436 (Needs Scheduling, no fix version) proposes layering the classic cache behind the SBE cache. [source]
Because the values in the `query` predicate are insignificant in determining the plan cache query shape, the following command would also remove the second index filter: [source]
Number of slot-based execution engine query plans that were not found in the query cache because the query is ineligible for caching. [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]
The [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization) typically selects the optimal index for a specific operation. However, you can force MongoDB to use a specific index using the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) method. Use [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) to support performance testing or when you are querying a field that appears in several indexes to ensure that MongoDB uses [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]
A hinted sparse index is used even when it would omit documents: the planner normally avoids a sparse index that gives incomplete results, but an explicit hint forces it and the query returns only documents containing the field. A hinted countDocuments with an empty predicate on a sparse index returns an incorrect count. [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]
Starting in MongoDB 6.0.7, if a usable clustered index exists, the MongoDB query planner evaluates the clustered index against secondary indexes in the query planning process. When a query uses a clustered index, MongoDB performs a [bounded collection scan.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-bounded-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]
Removes [index filters](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters) on a collection. Although index filters only exist for the duration of the server process and do not persist after shutdown, you can also clear existing index filters with the [`planCacheClearFilters`](https://www.mongodb.com/docs/manual/reference/command/plancacheclearfilters.md#mongodb-dbcommand-dbcmd.planCacheClearFilters) command. [source]
Number of classic execution engine query plans that were not found in the query cache because the query is ineligible for caching. [source]
| Parameter | Type | Description | | --- | --- | --- | | `index` | string or document | The index to "hint" or force MongoDB to use when performing the query. Specify the index either by the index name or by the index specification document. You can also specify `{ $natural : 1 }` to force the query to perform a forwards collection scan, or `{ $natural : -1 }` for a reverse collection scan. | [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]
Hinted index is the only index used, with no fallback to another index or collection scan; hinting by key pattern fails when several indexes share that pattern, so hint by name. min() and max() require a hint. [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]
As with any hash function, two different query shapes may result in the same hash value. However, the occurrence of hash collisions between different query shapes is unlikely. [source]
See [Plan Cache Flushes](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-plan-cache-flushes) for additional scenarios that trigger changes to the plan cache. [source]
fromPlanCache is true when the query planner is able to use a plan from the plan cache. [source]
Call this method on a query to override MongoDB's default index selection and [query optimization process](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization). Use [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getindexes.md#mongodb-method-db.collection.getIndexes) to return the list of current indexes on a collection. [source]
When evaluating the clauses in the [`$and`](https://www.mongodb.com/docs/manual/reference/operator/query/and.md#mongodb-query-op.-and) expression, MongoDB's query optimizer considers which indexes are available that could help satisfy clauses of the [`$and`](https://www.mongodb.com/docs/manual/reference/operator/query/and.md#mongodb-query-op.-and) expression when [selecting the best plan to execute.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization) [source]
Starting in MongoDB 8.3, if the FCV (feature compatibility version) is 8.3 or later, MongoDB backfills the `representativeQuery` field for query settings that you set with a query shape hash. When MongoDB runs a query that matches the query shape, it schedules the backfill. The backfill requires no action from you. [source]
Because `showDebugQueryShape` is `true`, the `debugQueryShape` document is included in the output. You can use the `queryShapeHash` identifier to locate the query settings. `queryShapeHash` and `debugQueryShape` are highlighted in this output: [source]
Classic multi-planning picks the winner as the plan that returns the most results in the trial period while doing the least work. The winner is stored in the plan cache and reused for queries with the same plan cache query shape. [source]
Each index suggestion includes an Average Query Targeting score indicating how many documents were read for every document returned for the index's corresponding query shapes. A score of 1 represents very efficient query shapes because every document read matched the query and was returned with the query results. All suggested indexes represent an opportunity to improve query performance. [source]
For example, the following query causes MongoDB to use the `timestamp_1_metadata.sensorId_1` index: [source]
Per SERVER-90880, queries run in SBE use the classic plan cache by default; the SBE plan cache is used only when featureFlagSbeFull is on. In 8.0 only $group/$lookup-type queries tend to run in SBE. [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]
Percona PMM can retain index-usage metrics across restarts when the exporter is started with -collect.indexusage (not on by default); as of the 2018 post, the metrics lacked database and collection labels, so collection-level filtering was not possible. Likely outdated. [source]
When you sort based on an array field that is indexed with a [multikey index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md#std-label-index-type-multikey), the query plan includes an [in-memory sort](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-in-memory-sort) stage unless both of the following are true: [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]
Index properties affect how the query planner uses an index and how indexed documents are stored. You can specify index properties as optional parameters when you create an index. [source]
Starting in MongoDB 8.3, multi-planning with a cost-based ranker 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 within the timeframe. [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]
Atlas 'Query Targeting: Scanned Objects / Returned' alerts when average documents scanned divided by average documents returned, server-wide over a sampling period, exceeds a threshold. The default threshold is 1000:1 and the docs say the ideal ratio is close to 1. [source]
Index hints cause MongoDB to use a specific index for a query. Some operations on time series collections can only take advantage of an index if that index is specified in a hint. [source]
If you include a [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) that specifies a [sparse index](https://www.mongodb.com/docs/manual/core/index-sparse.md#std-label-index-type-sparse) when you perform a [`count()`](https://www.mongodb.com/docs/manual/reference/method/cursor.count.md#mongodb-method-cursor.count) of all documents in a collection (i.e. with an empty query predicate), the sparse index is used even if the sparse index results in an incorrect count. [source]
Index filters exist for the duration of the server process and do not persist after shutdown. MongoDB also provides a command to manually remove filters. [source]
When evaluating the clauses in the [`$or`](https://www.mongodb.com/docs/manual/reference/operator/query/or.md#mongodb-query-op.-or) expression, MongoDB performs a collection scan or an index scan. If all clauses are supported by indexes, MongoDB performs index scans. To use indexes to evaluate an [`$or`](https://www.mongodb.com/docs/manual/reference/operator/query/or.md#mongodb-query-op.-or) expression, all the clauses in the [`$or`](https://www.mongodb.com/docs/manual/reference/operator/query/or.md#mongodb-query-op.-or) expression must be supported by indexes. Otherwise, MongoDB performs a co [source]
Recommended indexes are accompanied by sample queries, grouped by [query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-shape), that were run against a collection that would benefit from the suggested index. The Performance Advisor considers workload activity across all nodes in the replica set, including secondaries, when generating index recommendations. The Performance Advisor doesn't negatively affect the performance of your Atlas clusters. [source]
The index definitions laid out in the previous section illustrate one of the flexibility enhancements of `$search`. In order to create the `$text` index on `sample_mflix.movies`, you must first delete any existing text index on the sample data using the [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndex.md#mongodb-method-db.collection.dropIndex) method, as MongoDB supports only a single text index per collection. [source]
The index only supports queries on fields included in the `wildcardProjection` object. In this example, MongoDB performs a collection scan for the following query because it includes a field that is not present in the `wildcardProjection` object: [source]
For replica sets, run [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) on the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary). The primary stops the index build and creates an associated "abortIndexBuild" [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) entry. Secondaries which replicate the "abortIndexBuild" oplog entry stop the in-progress index build and discard the build job. See [Index Build Process](https://www.mongodb [source]
The [`notablescan`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.notablescan) parameter does not allow unbounded queries that use a clustered index because the queries require a full collection scan. [source]
When an index covers a query, the explain result has an `IXSCAN` stage that is **not** a descendant of a `FETCH` stage. [source]
The notablescan parameter does not allow unbounded queries that use a clustered index because the queries require a full collection scan. [source]
Each $indexStats result document carries name, key, host, accesses {ops, since}, spec, and shard (sharded clusters only); building appears only when true and spec.hidden only when true. accesses.ops counts user operations that used the index; accesses.since is when statistics gathering began. [source]
Detection recipe: run $indexStats then filter accesses.ops equal to 0 (excluding _id_); treat as candidates only after a representative window. Netdata suggests at least 24h uptime under representative load and a full workload cycle if a restart happened after the since timestamp; Percona warns monthly or end-of-day reporting indexes can be missed by short windows. [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]
1. When a project becomes eligible, Atlas sends the first report approximately one hour after the [`Query Targeting: Scanned Objects / Returned`](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#mongodb-alert-Query-Targeting--Scanned-Objects---Returned) alert. [source]
Turn the toggle on to subscribe or off to unsubscribe. When subscribing for the first time, select the cluster or clusters that you want the report to cover. The change applies to all [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) users in the project. [source]
Specifies the maximum number of lock timeouts per second when trying to write to [`profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collections. Once this threshold is reached, profiling is disabled for this database. This setting lasts until you manually re-enable profiling. [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]
The [default](https://www.mongodb.com/docs/atlas/configure-alerts.md#std-label-default-alert-settings) [`Query Targeting: Scanned Objects / Returned`](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#mongodb-alert-Query-Targeting--Scanned-Objects---Returned) alert ratio differs slightly. The ratio of the average number of documents scanned to the average number of documents returned during a sampling period triggers this alert. [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]
fromMultiPlanner is true when the query planner evaluates multiple plans before choosing the winning execution plan for the query. [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]
The number of queries that exceeded the threshold that the [`maxEstimatedScanBytes`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.maxEstimatedScanBytes) parameter sets but that the server ran anyway because a `$natural` hint overrode the rejection. [source]
For example, `$group` operations of the following form can result in a `DISTINCT_SCAN`: [source]
Views are the result of aggregation pipelines. When you use $sample on a view, MongoDB appends the stage to the end of the view's aggregation pipeline syntax. Therefore, the $sample stage on a view is never the first stage and always results in a collection scan. [source]
Because the database profiler writes data to the system.profile collection in a database, the profiler profiles some write activity, even for databases that are otherwise read-only. [source]
When using Queryable Encryption, CRUD operations against encrypted collections are omitted from the system.profile collection. For details, see Redaction. [source]
Atlas Infinite clusters only support this command when the [database profiler level](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-level) is `0`. [source]
Changes made to the profiling level with `db.setProfilingLevel()` do *not* persist. When the server restarts, it reverts to `0` (the default), or the value set by either the [`operationProfiling.mode`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-operationProfiling.mode) setting or the [`--profile`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--profile) command-line option. [source]
- a [filter](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-options-filter) of `{ op: "query", millis: { $gt: 2000 } }`, which causes the profiler to only record `query` operations that took longer than 2 seconds. [source]
Because the profiling level is `0`, the profiler is disabled and does not record matching operations to the profiler collection. The filter still applies to the diagnostic log. [source]
Don't run production [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instances with [`notablescan`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.notablescan) because preventing collection scans can potentially affect queries in all databases, including administrative queries. [source]
You can set a `filter` to control which operations are logged by the profiler. When set, any configured filters are also returned by [`db.getProfilingStatus()`](https://www.mongodb.com/docs/manual/reference/method/db.getprofilingstatus.md#mongodb-method-db.getProfilingStatus), along with a `note` explaining filter behavior. [source]
Number of times this MongoDB process failed to store a new query stats key. Generally, these failures happen when the `$queryStats` virtual collection runs out of space. [source]
Number of times this MongoDB process failed to compute a one-way tokenized query stats key when `$queryStats` was called with the `transformIdentifiers` option. [source]
Number of post-recovery waits that completed when the cluster's config time advanced since the server started. [source]
When set to level `2`, the profiler ignores user provided values for `slowms` and `filter`. [source]
Because $queryStats reports only the operations that MongoDB samples, its output represents a subset of the operations run against your deployment. Counts and execution times reflect only the sampled operations. [source]
When an HMAC key is specified to the transformIdentifiers option, $queryStats uses the HMAC key to apply an HMAC-SHA-256 hash function on the following data: [source]
In sharded clusters, MongoDB records query statistics separately on each mongod and mongos when $queryStats is enabled. Shard servers also record statistics for queries that originate from mongos. These provide more complete shard-level metrics for queries that users route through mongos. [source]
usedDisk is true when the query writes data to temporary files due to memory restrictions. [source]
When Atlas runs $queryStats on your deployment, it uses a unique HMAC key per Atlas organization to transform your data and avoid collecting sensitive information. [source]
When using [Queryable Encryption](https://www.mongodb.com/docs/manual/core/queryable-encryption.md#std-label-qe-manual-feature-qe), the `$planCacheStats` stage omits operations against encrypted collections, even though the operations are cached as normal. [source]
When the `allHosts` option is set to `false`, [`$planCacheStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/plancachestats.md#mongodb-pipeline-pipe.-planCacheStats) follows the [read preference](https://www.mongodb.com/docs/manual/core/read-preference.md#std-label-read-preference) in selecting the host(s) from which to return the plan cache information. [source]
Because the database profiler writes data to the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection in a database, the profiler profiles some write activity, even for databases that are otherwise read-only. [source]
When using [Queryable Encryption](https://www.mongodb.com/docs/manual/core/queryable-encryption.md#std-label-qe-manual-feature-qe), CRUD operations against encrypted collections are omitted from the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection. For details, see [Redaction.](https://www.mongodb.com/docs/manual/core/queryable-encryption/reference/limitations.md#std-label-qe-redaction) [source]
Number of times the operation had to wait for the [`acquireCount`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.acquireCount) lock acquisitions because the locks were held in a conflicting mode. [`acquireWaitCount`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.acquireWaitCount) is less than or equal to [`acquireCount`.](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.acquireCount) [source]
When MongoDB writes query profile information to the log, the [`responseLength`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.responseLength) value is in a field named `reslen`. [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]
The following examples show the differences in log messages when `$queryStats` output is included. [source]
Each field has the form `{ "value": <value>, "source": <string> }`. When you set a query knob with the [`setQuerySettings`](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) command, MongoDB sets the `source` value to `"querySettings"`. When you set a query knob with [`setParameter`](https://www.mongodb.com/docs/manual/reference/command/setparameter.md#mongodb-dbcommand-dbcmd.setParameter), MongoDB sets the `source` value to `"setParameter"`. [source]
The Query Profiler samples operations by using a bucketing algorithm that adjusts the sample size based on the width of the selected time range. Because of differences in bucket size, a wider time range might display fewer sampled operations than a narrower time range. For exact, unsampled operation counts, download your `mongod` logs. To learn more, see [View and Download MongoDB Logs.](https://www.mongodb.com/docs/atlas/mongodb-logs.md#std-label-mongodb-logs) [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]
mongos performs a broadcast operation for queries that do not include the shard key, routing queries to all shards in the cluster. Some queries that do include the shard key may still result in a broadcast operation depending on the distribution of data in the cluster and the selectivity of the query. [source]

How-to and procedures

Set an [index filter](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters) for a collection. If an index filter already exists for the [plan cache query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape), the command overrides the previous index filter. [source]
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]
To choose the best query plan, the query optimizer evaluates the [`indexes`](https://www.mongodb.com/docs/manual/reference/command/plancachelistfilters.md#mongodb-data-planCacheListFilters.filters.indexes) *and* the collection scan. [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 provide more insight into the [query plan cache](https://www.mongodb.com/docs/manual/core/query-plans.md), MongoDB offers the `planCacheKey`. [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 see the query shapes for which cached query plans exist, see [Examples.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/plancachestats.md#std-label-planCacheStats-examples) [source]
To add query settings and explore examples, which include explain() output with querySettings, see setQuerySettings. [source]
Use `$natural` in conjunction with `cursor.hint()` to perform a collection scan to return documents in [natural order.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-natural-order) [source]
To add query settings for a query shape, use setQuerySettings. [source]
To verify that the slot-based execution engine is used, run the aggregation with the `explain` option. This option outputs information on the aggregation's query plan. For more information on using `explain` with aggregations, see [Return Information on Aggregation Pipeline Operation.](https://www.mongodb.com/docs/manual/reference/method/db.collection.aggregate.md#std-label-example-aggregate-method-explain-option) [source]
To return plan cache information for a particular query hash, the [`$planCacheStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/plancachestats.md#mongodb-pipeline-pipe.-planCacheStats) stage can be followed by a [`$match`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/match.md#mongodb-pipeline-pipe.-match) on the `planCacheKey` field. [source]
To delete query settings, you must provide either a [query shape](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) hash string or a query shape to `removeQuerySettings`. [source]
To find a hash string or query shape, you can use a [`$querySettings`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querysettings.md#mongodb-pipeline-pipe.-querySettings) stage in an aggregation pipeline. The hash string is named `queryShapeHash` in the `$querySettings` output. [source]
To locate the query settings to delete, use the `queryShapeHash` string in this output: [source]
To hide an index, you must have [featureCompatibilityVersion](https://www.mongodb.com/docs/manual/reference/command/setfeaturecompatibilityversion.md#std-label-view-fcv) set to `7.0` or greater. [source]
To see the index used, run [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) on the operation: [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 force MongoDB to use a particular index, use cursor.hint() (mongosh method) when testing indexes. [source]
To use an index with the [`max()`](https://www.mongodb.com/docs/manual/reference/method/cursor.max.md#mongodb-method-cursor.max) method, you must use the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) method to specify the index you want to use, except when the [`find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find.md#mongodb-method-db.collection.find) query is an equality condition on the `_id` field. [source]
To view query performance in the Query Profiler, you must have [`Project Read Only`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Read-Only) or [`Project Observability Viewer`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Observability-Viewer) access to the project. [source]
To obtain the correct count of the number of documents in the `movies` collection, do not [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) with a [sparse index](https://www.mongodb.com/docs/manual/core/index-sparse.md#std-label-index-type-sparse) when performing a count of all documents in a collection. [source]
To use the sparse index, explicitly specify the index with [`hint()`:](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) [source]
To view query performance in the Query Profiler, you must have Project Read Only or Project Observability Viewer access to the project. [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 change the other index options, drop the existing index with [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) before running [`db.collection.createIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindexes.md#mongodb-method-db.collection.createIndexes) with the new options. [source]
To drop an index, insert the index name and run [db.collection.dropIndex().](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#std-label-collection-drop-index) [source]
To establish recommended indexes, the Performance Advisor uses these metrics in a formula to calculate the Impact, or performance improvement that creating an index matching that query shape would cause. When the Performance Advisor suggests indexes, it ranks the indexes by their Impact. The Impact is determined by the total wasted bytes read. [source]
Use the dropIndexes command or its shell helpers dropIndex() or dropIndexes() to terminate an in-progress index build. See Stop In-Progress Index Builds for more information. [source]
To get the index name or the index specification document for the [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) method, use the [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getindexes.md#mongodb-method-db.collection.getIndexes) method. [source]
To drop a specific index, use the [`dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) method and specify the index name: [source]
To drop multiple indexes, use the [`dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindexes.md#mongodb-method-db.collection.dropIndexes) method and specify an array of index names: [source]
To drop all indexes except the `_id` index, use the [`dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindexes.md#mongodb-method-db.collection.dropIndexes) method: [source]
To sort by a metric in descending or ascending order, click the sort icon next to the associated column name once or twice, respectively. To sort by multiple columns, press Shift and click the sort icons in the order in which you want to multi-sort the table. [source]
To learn more about the command syntax and parameters, see the Atlas CLI documentation for [atlas performanceAdvisor slowQueryLogs list.](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-performanceAdvisor-slowQueryLogs-list/) [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 view the query plan, click Explain in the query bar. [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 return information on [query plans](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) and execution statistics of the query plans, MongoDB provides the following methods: [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 bypass rejection for a specific query, add a `$natural` hint to the query. [source]
To remove query settings, use [`removeQuerySettings`](https://www.mongodb.com/docs/manual/reference/command/removequerysettings.md#mongodb-dbcommand-dbcmd.removeQuerySettings). To see current query settings, use a [`$querySettings`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querysettings.md#mongodb-pipeline-pipe.-querySettings) stage in an aggregation pipeline. [source]
Use this endpoint to reject a query shape (preventing it from executing on the cluster) or to unreject a previously rejected query shape (allowing it to execute again). This operation is idempotent: rejecting an already rejected query shape or unrejecting an already unrejected query shape will return 200 OK. [source]
To view more details about a query shape, click on the row for the query shape to open the Query Shape Details view. This view contains the full query shape and query shape hash, each table metric listed above, and the following additional metrics: [source]
To view the current profiling level, see [`db.getProfilingStatus()`.](https://www.mongodb.com/docs/manual/reference/method/db.getprofilingstatus.md#mongodb-method-db.getProfilingStatus) [source]
To clear a profile filter, run `db.setProfilingLevel()` with the `filter: "unset"` option. [source]
To add query settings and explore examples, see [`setQuerySettings`.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) [source]
To delete query settings, use removeQuerySettings. [source]
To retrieve query settings, use a $querySettings stage in an aggregation pipeline. [source]
To block a query shape, use an operation rejection filter. [source]
To remove query settings, use removeQuerySettings. To obtain the query settings, use a $querySettings stage in an aggregation pipeline. [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]
To set the `reject` field, use `setQuerySettings`. [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]
To view metrics with Query Shape Insights, you must have Project Observability Viewer, Project Data Access Read Only, Project Data Access Read/Write, Project Data Access Admin, or Project Owner access to the project. [source]
To run $queryStats without the transformIdentifiers option, the user must have the queryStatsRead privilege action. [source]
To run $queryStats with the transformIdentifiers option, the user must have the both the queryStatsRead and queryStatsReadTransformed privilege actions. [source]
To learn how to control $queryStats logging behavior, see Toggle $queryStats Log Output. [source]
To use the MongoDB Node.js driver to add a $queryStats stage to an aggregation pipeline, use the $queryStats operator in a pipeline object. [source]
To learn how to control `$queryStats` logging behavior, see [Toggle $queryStats Log Output.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats/toggle-logging.md#std-label-queryStats-toggle-logging) [source]
To enable or disable Performance Advisor and the Query Profiler for a project, you must have the [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) role for the project or the [`Organization Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Organization-Owner) role on its parent organization. [source]
To enable or disable Performance Advisor and the Query Profiler for a project, you must have the Project Owner role for the project or the Organization Owner role on its parent organization. [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 — `db.runCommand(` … [source]
```javascript — `db.runCommand(` … [source]
```javascript — `db.runCommand(` … [source]
```javascript — `executionStats: {` … [source]
```javascript — `version: '2',` … [source]
```javascript — `db.adminCommand( {` … [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.users.find().hint( { $natural : 1 } )` … [source]
```javascript — `db.users.find().hint( { $natural : -1 } )` … [source]
```javascript — `db.orders.aggregate( [` … [source]
```javascript — `queryShapeHash: 'AB8ECADEE8F0EB0F447A30744EB4813AE7E0BFEF523B0870CA10FCBC87F5D8F1'` … [source]
```javascript — `queryShapeHash: 'AC1ECADBE8F1EB0F417A30741AB4813BE7E0BFEF523B0870CA11FCBC87F1A8B2'` … [source]
```javascript — `db.adminCommand( {` … [source]
```javascript — `db.movies.find(` … [source]
```javascript — `key: {` … [source]
```javascript — `{ // Plan Cache Entry 1` … [source]
```javascript — `db.adminCommand( {` … [source]
```java — `var hintPipeline = Arrays.asList(` … [source]
```javascript — `db.sensorData.find( { "metadata.sensorId": 5578 } ).hint( "timestamp_1_metadata.sensorId_1" )` … [source]
```python — `hint_result = list(collection.aggregate(` … [source]
```javascript — `db.users.find().hint( { age: 1 } )` … [source]
```javascript — `db.users.find().hint( "age_1" )` … [source]
```javascript — `db.products.find( { _id: { $in: [ 6, 7 ] } } ).min( { price: Decimal128("1.39") } ).hint( { price: 1 } )` … [source]
```javascript — `title: "The Shawshank Redemption",` … [source]
```javascript — `db.orders.find(` … [source]
```javascript — `db.movies.find().sort( { plot: -1 } ).hint( { plot: 1 } ).limit(5)` … [source]
```javascript — `planCache : {` … [source]
```javascript — `db.orders.aggregate( [ { $indexStats: { } } ] )` … [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]
```javascript — `db.salesData.dropIndex( "tenant_customFields" )` … [source]
```javascript — `db.<collection>.dropIndexes( [ "<index1>", "<index2>", "<index3>" ] )` … [source]
```javascript — `db.<collection>.dropIndexes()` … [source]
```javascript — `"query" : { "status" : "A" },` … [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]
```javascript — `db.movies.createIndex( { year: 1 } )` … [source]
```javascript — `"op" : "query",` … [source]
```javascript — `db.runCommand(` … [source]
```javascript — `db.runCommand({` … [source]
```javascript — `{ "item": "canvas", "qty": 100, "size": { "h": 28, "w": 35.5, "uom": "cm" }, "status": "A" },` … [source]
```text — `atlas clusters search indexes create [indexName] [options]` … [source]
```javascript — `{ "item": "journal", "qty": 25, "tags": ["blank", "red"], "dim_cm": [ 14, 21 ] },` … [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]
```shell — `atlas api queryShapeInsights getClusterQueryShape --version 2025-03-12 --clusterName [clusterName] --groupId 3` … [source]
```javascript — `db.runCommand(` … [source]
```javascript — `db.setProfilingLevel(<level>, <options>)` … [source]
```javascript — `"was" : 2,` … [source]
```javascript — `db.setProfilingLevel( 1, { filter: { op: "query", millis: { $gt: 2000 } } } )` … [source]
```javascript — `db.setProfilingLevel( 1, { filter: "unset" } )` … [source]
```javascript — `{ querySettings: { queryKnobs: { operationResponseMaxMS: <value> } } }` … [source]
```javascript — `{ $indexStats: { } }` … [source]
```javascript — `db.pets.dropIndex( "catIdx" )` … [source]
```javascript — `db.pets.dropIndex( { "cat" : -1 } )` … [source]
```json — `indexStats: {` … [source]
```javascript — `profiler: {` … [source]
```javascript — `queryStats: {` … [source]
```javascript — `querySettings: {` … [source]
```javascript — `db.products.find(` … [source]
```javascript — `db.movies.explain( "allPlansExecution" ).findAndModify( {` … [source]
```javascript — `var cursor = db.users.find(` … [source]
```javascript — `db.system.profile.find( { "command.aggregate": "movies", "command.comment" : "match_three_movies_from_1994" } ` … [source]
```javascript — `db.adminCommand( {` … [source]
```javascript — `db.getSiblingDB("admin").aggregate( [` … [source]
```javascript — `key: {` … [source]
```javascript — `db.getSiblingDB("admin").aggregate( [` … [source]
```javascript — `$planCacheStats: {` … [source]
```javascript — `db.orders.aggregate( [` … [source]
```javascript — `"inprog": [` … [source]
```javascript — `db.aggregate( [` … [source]
```javascript — `db.inventory.find(` … [source]
```javascript — `"t":{"$date":"2026-08-14T13:36:19.194-04:00"},"s":"D1",` … [source]
```javascript — `db.runCommand(` … [source]
```javascript — `db.runCommand(` … [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

The default slowms threshold is 100 ms and default sampleRate is 1.0. slowms and sampleRate are global (all databases in the process); profiling level and filter are per database when set via db.setProfilingLevel() but process-wide when set on the command line or config file. [source]
Profiler output goes to system.profile, a capped collection per database with a default size of 1 MB (roughly several thousand documents). To resize it, disable profiling, drop it, recreate it with db.createCollection('system.profile', {capped:true, size:N}), then re-enable profiling. [source]
Starting in MongoDB 5.0, the [plan cache](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) will save full `plan cache` entries only if the cumulative size of the `plan caches` for all collections is lower than 0.5 GB. When the cumulative size of the `plan caches` for all collections exceeds this threshold, additional `plan cache` entries are stored without the following debug information: [source]
- A percentage of the system's total physical memory to allocate for the plan cache. For example, `"8.5%"`. [source]
- The exact amount of data to allocate for the plan cache in either `MB` or `GB`. For example, `"100MB"` or `"1GB"`. [source]
The classic multi-planner's trial is bounded to the larger of 10,000 storage reads or 30% of the collection (internalQueryPlanEvaluationCollFraction). SERVER-62981, fixed in 5.2.1/5.3.0, proposed internalQueryPlanEvaluationCollFractionSbe (default 0, meaning 10,000 reads per candidate) for SBE. The shipped SBE default was not confirmed. [source]
Sampling differs by version: Atlas on 8.x records up to 100 read queries/s per host and no writes; from MongoDB 9.0 $queryStats samples 1% of reads and writes by default (internalQueryStatsSampleRate, internalQueryStatsWriteCmdSampleRate, 0.0-1.0). Infrequent shapes may be missing and totals jump after an 8.x to 9.0 upgrade. [source]
- On clusters running MongoDB 9.0 or later, Atlas randomly samples 1% of read and write operations by default. Displayed metric values reflect only sampled operations, approximately 1% of total operations. Query shapes that run infrequently may not appear in the results. This method also collects write operations (`insert`, `update`, and `delete`), which appear in Query Shape Insights alongside read operations. [source]
In MongoDB 9.0, the default value changes from `0` to `0.01`, which enables query stats collection for read operations at a default sampling rate of 1%. [source]
Starting in MongoDB 9.0, $queryStats collects stats for a sample of 1% of read and write operations by default. To change the sampling rate, set the internalQueryStatsSampleRate parameter for read operations or the internalQueryStatsWriteCmdSampleRate parameter for write operations. Both parameters accept a value between 0.0 and 1.0. [source]
nreturned:4 protocol:op_query 358ms [source]
Full $planCacheStats debug info (createdFromQuery, cachedPlan, creationExecStats, candidatePlanScores) is kept only while total plan cache size across all collections is under 0.5 GB (since 5.0). Since 6.3 the planCacheSize parameter sets the cache size, with a default of 5% of memory (per Percona). [source]
$queryStats stores entries in an in-memory virtual collection limited to 1% of system memory. Each entry is keyed by query shape plus client info, read concern and collection type, so one shape can produce several entries; keyHash identifies the entry and queryShapeHash groups entries by shape. [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]
| Field | Type | Description | | --- | --- | --- | | `distinct` | string | The name of the collection to query for distinct values. | | `key` | string | The field for which to return distinct values. | | `query` | document | Optional. A query that specifies the documents from which to retrieve the distinct values. | | `readConcern` | document | Optional. Specifies the [read concern.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-read-concern) The `readConcern` option has the following syntax: `readConcern: { level: <value> }` Possible read concern levels are: [`"local"`](h [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]
Settings can be set by passing a full find/distinct/aggregate command plus $db, or by passing an existing query shape hash string; the hash is obtainable from $querySettings (queryShapeHash), the profiler, or slow query logs. Hash-created settings lack representativeQuery until 8.3 (FCV 8.3+), which backfills it asynchronously, best effort. [source]
Explain exposes queryShapeHash and planCacheShapeHash at the top level; SERVER-91954 added it (fixed in 8.0.4 and 8.1.0-rc0, resolved 2024-09-20). Before that, the hash was only available from the slow query log/profiler or via setQuerySettings plus $querySettings. [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]
A replanning loop occurs when data changes faster than the planner adapts. Causes: data-dependent filter values, non-selective indexes, near-tied plans, rapid cardinality change (bulk insert/delete, TTL, capped overwrite), and $or/$in/$regex with variable item counts. Diagnose with slow-log fields replanned: true, replanReason, planningTimeMicros, fromMultiPlanner, queryHash and planCacheKey. [source]
Mitigations for plan instability: add more selective indexes, avoid generic queries, cap $or/$in value counts, use hint() as a short-term stabilizer, or use 8.0 query settings for a cluster-wide hint. Index filters (planCacheSetFilter) are deprecated from 8.0 in favor of query settings, and they do not persist across shutdown. [source]
Query settings have more functionality than index filters. Also, index filters aren't persistent and you cannot easily create index filters for all cluster nodes. To add query settings and explore examples, see [`setQuerySettings`.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) [source]
| Field | Type | Description | | --- | --- | --- | | `query` | document | Optional. The query predicate of the plan cache query shape. Only the structure of the predicate, including the field names, are significant to the shape; the values in the query predicate are insignificant. | | `projection` | document | Optional. The projection associated with the plan cache query shape. | | `sort` | document | Optional. The sort associated with the plan cache query shape. | | `comment` | any | Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records [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]
The new 8.0 query shape covers find, distinct and aggregate (the entire pipeline) and powers setQuerySettings, operation rejection filters and $queryStats; the plan cache query shape supports plan caching, deprecated index filters and only a subset of aggregation. [source]
Slow-query entries and profiler documents include planCacheShapeHash (duplicate of queryHash since 8.0; queryHash is deprecated) and planCacheKey, to group slow queries by plan cache query shape. planCacheKey changes when supporting indexes are added or dropped; the shape hash does not. [source]
[ { "x.a": { $gt: 85 } }, { "x.b": { $gt: 80 } } ]` However, you can specify compound conditions on the same identifier in a single filter document, such as in the following examples: `// Example 1 [ { $or: [{"x.a": {$gt: 85}}, {"x.b": {$gt: 80}}] } ] // Example 2 [ { $and: [{"x.a": {$gt: 85}}, {"x.b": {$gt: 80}}] } ] // Example 3 [ { "x.a": { $gt: 85 }, "x.b": { $gt: 80 } } ]` For examples, see [Array Update Operations with `arrayFilters`.](https://www.mongodb.com/docs/manual/reference/command/findandmodify.md#std-label-findAndModify-command-arrayFilters) `arrayFilters` is not available for u [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]
Hidden indexes let you trial a drop: db.collection.hideIndex() (collMod index.hidden) removes the index from planner selection but keeps maintaining it, so unhide is instant. Requires featureCompatibilityVersion 7.0 or greater per the current manual; the _id index cannot be hidden; needs collMod privilege (dbAdmin). [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]
Index filters (planCacheSetFilter) are deprecated from 8.0; docs say use query settings instead because index filters are not persistent and cannot easily be created for all cluster nodes. [source]
reject: true rejects new matching queries but not in-progress ones. To re-enable, run setQuerySettings with reject:false alongside other settings; a settings document containing only reject:false returns an error, so use removeQuerySettings then set again. [source]
Early 8.0 bugs: SERVER-89118 (setQuerySettings could trip invariant 8758500 under concurrent removal, or removeQuerySettings then setQuerySettings via different mongoses) was fixed in 8.0.0-rc4; SERVER-89340 (setQuerySettings on an aggregate with $bucket failing with error 40199) was closed Won't Fix. [source]
The above unsupported index types are ignored by the query planner in strict mode. For example, attempting to use a sparse index with cursor.hint() results in the following BadValue error: [source]
- The above unsupported index types are ignored by the [query planner](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) in [strict mode](https://www.mongodb.com/docs/manual/reference/stable-api.md#std-label-stable-api-strict-client). For example, attempting to use a `sparse` index with [`cursor.hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) results in the following `BadValue` error: [source]
```text planner returned error :: caused by :: hint provided does not correspond to an existing index ``` [source]
planCacheShapeHash (new in 8.0, a duplicate of the deprecated queryHash) depends only on query shape. planCacheKey depends on shape and the available indexes, so adding or dropping a supporting index can change planCacheKey but not planCacheShapeHash. [source]
Query settings have more functionality and are preferred over deprecated [index filters.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters) [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]
planner returned error :: caused by :: hint provided does not [source]
deprecated index filters. (Starting in MongoDB 8.0, use the new query settings for the new query shape.) [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]
The backfill runs asynchronously on a best-effort basis to limit the performance impact on your queries. A query setting isn't guaranteed to be backfilled the first time a matching query runs. If a backfill doesn't complete, MongoDB attempts it again the next time a matching query runs. [source]
To hold the additional representative queries, MongoDB 8.3 also increases the storage capacity for representative queries in query settings beyond the original 16 MB BSON document limit. [source]
The slow operation threshold is shared by the profiler and the diagnostic log. With logLevel 0, slow operations are logged at a rate set by slowOpSampleRate; at higher log verbosity all operations are logged regardless of latency. [source]
Slow-query log fields have grown by version: queryFramework (6.2), cpuNanos on Linux (6.3), queues and queryShapeHash (8.0), spill metrics (8.1), originalQueryShapeHash, slow in-progress entries via slowOpInProgressThresholdMs and a deadline field (8.3), and queryKnobs (9.0). [source]
Atlas dynamically adjusts its slow query threshold by default (used by Performance Advisor and Query Profiler); users can opt out to a fixed 100 ms and MongoDB advises against going lower. Free (M0) clusters have the managed threshold disabled and it cannot be enabled; clusters with MongoDB Search do not support it. Toggling needs Project Owner. [source]
Since MongoDB 5.0, changes to profiler level, slowms, sampleRate or filter are written to the log file. Secondaries also log oplog applications slower than the threshold; the profiler does not capture slow oplog entries. [source]
planCacheKey to provide more insight into the query plan cache for slow queries. [source]
Starting in MongoDB 9.0, slow query logs include a `planRankerMethod` field that indicates which [query plan ranking mechanism](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plan-options) selected the winning plan: [source]
- `planCacheKey` to provide more insight into the [query plan cache](https://www.mongodb.com/docs/manual/core/query-plans.md) for slow queries. [source]
| Field | Type | Description | | --- | --- | --- | | `limit` | integer | Optional. The maximum number of documents to count. | | `skip` | integer | Optional. The number of documents to skip before counting. | | `hint` | string or document | Optional. An index name or the index specification to use for the query. | | `maxTimeMS` | integer | Optional. The maximum amount of time to allow the count to run. | [source]
| Field | Type | Description | | --- | --- | --- | | `limit` | integer | Optional. The maximum number of documents to count. | | `skip` | integer | Optional. The number of documents to skip before counting. | | `hint` | string or document | Optional. An index name hint or specification for the query. | | `maxTimeMS` | integer | Optional. The maximum amount of time to allow the query to run. | | `readConcern` | string | Optional. Specifies the [read concern](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-read-concern). The default level is [`"local"`.](https://www.mongodb.co [source]
To see an example log message for a query that used the slot-based execution engine, see [Slow Operation.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-examples-slow-op) [source]
| Name | Type | Required | Description | | --- | --- | --- | --- | | --clusterName | string | true | Human-readable label that identifies the cluster. | | --envelope | envelope | false | Flag that indicates whether Application wraps the response in an envelope JSON object. Some API clients cannot access the HTTP response headers or status code. To remediate this, set envelope=true in the query. Endpoints that return a list of results use the results object as an envelope. Application adds the status parameter to the response body. | | --groupId | string | true | Unique 24-hexadecimal digit str [source]
To help identify slow queries with the same [plan cache query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape), each plan cache query shape is associated with a query hash. The plan cache query shape hash is a hexadecimal string that represents a hash of the query shape and is dependent only on the query shape. [source]
| Field | Type | Description | | --- | --- | --- | | `createIndexes` | string | The collection for which to create indexes. | | `indexes` | array | Specifies the indexes to create. Each document in the array specifies a separate index. | | `writeConcern` | document | Optional. A document expressing the [write concern](https://www.mongodb.com/docs/manual/reference/write-concern.md). Omit to use the default write concern. | | `commitQuorum` | integer or string | Optional. The minimum number of data-bearing replica set members (i.e. commit quorum), including the primary, that must report a succes [source]
| Name | Type | Required | Description | | --- | --- | --- | --- | | --clusterName | string | true | Human-readable label that identifies the cluster. | | --commands | & | false | Retrieve query shape statistics matching specified MongoDB commands. To include multiple commands, pass the parameter multiple times delimited with an ampersand (&) between each command. The currently supported parameters are: find, distinct, aggregate, count, insert, update, and delete. The insert, update, and delete commands return results only for clusters running MongoDB 9.0 or later with write query shape statis [source]
planCacheShapeHash to help identify slow queries with the same plan cache query shape. [source]
The queryShapeHash field for a query shape is also included in the slow query log when available. [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]
- `planCacheShapeHash` to help identify slow queries with the same [plan cache query shape.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) [source]
This task uses [`$currentOp`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/currentop.md#mongodb-pipeline-pipe.-currentOp) to identify slow queries currently running on your application. To find all slow queries within a specified period, consider using a profiler. [source]
Since MongoDB 7.0, passing any $natural hint value other than 1 or -1 returns an error; earlier versions accepted invalid values such as 0, NaN, 'X' and -0.01. [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]
| Field | Type | Description | | --- | --- | --- | | `getMore` | long | The cursor identifier. | | `collection` | string | The name of the collection over which the cursor is operating. | | `batchSize` | positive integer | Optional. The maximum number of documents returned for each batch. If `batchSize` is not set, `getMore` returns up to 16 mebibytes (MiB) for each batch. If `batchSize` is set, `getMore` returns the lesser of `batchSize` documents or 16 MiB. | | `maxTimeMS` | non-negative integer | Optional. Specifies how long the server waits for new documents matching a [tailable cursor](ht [source]
[Hidden indexes](https://www.mongodb.com/docs/manual/core/index-hidden.md#std-label-index-type-hidden) are not visible to the [query planner](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) and cannot be used to support a query. [source]
Hidden indexes are not visible to the query planner and cannot be used to support a query. [source]
- If a query includes a `$text` expression, you cannot use [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) to specify which index to use for the query. [source]
- If you use [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) on a [hidden index](https://www.mongodb.com/docs/manual/core/index-hidden.md) or an index that doesn't exist, the operation returns an error. [source]
| Profiler | Description | | --- | --- | | [Atlas Query Profiler](https://www.mongodb.com/docs/atlas/tutorial/query-profiler.md#std-label-query-profiler) | Provides a scatterplot chart to Atlas customers, making it easy to identify slow queries and performance outliers. | | [Database Profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) | Stores query performance information in a collection, allowing you to query MongoDB for queries with specific performance issues. | [source]
Starting in MongoDB 8.3, creating an index with the name of `"_id_"` or specifying a hint of `"_id_"` on time series collections returns an error. [source]
You cannot cursor.hint() a hidden index. [source]
If a sparse index would result in an incomplete result set for queries and sort operations, MongoDB will not use that index unless a [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) explicitly specifies the index. See [Sparse Index On A Collection Cannot Return Complete Results](https://www.mongodb.com/docs/manual/core/index-sparse.md#std-label-sparse-index-incomplete-results) for an example. [source]
hint() cannot select the index for a query containing a $text expression. [source]
Hint is applicable beyond find(): aggregate takes it as an options field, and update/delete/count accept it; a hardcoded hint naming a dropped or renamed index becomes a hard failure. [source]
Query settings have more functionality than index filters. Index filters aren't persistent, and you can't easily create index filters for all cluster nodes. [source]
The `ship.coordinates` field contains embedded arrays. Wildcard indexes do not record individual values of embedded arrays. Instead, they record the entire embedded array. As a result, the wildcard index cannot support a match on an embedded array value, and MongoDB fulfills the query with a collection scan. [source]
Prevents running some collection scans when an index could be used, whether present or not. If `true`, MongoDB will not execute queries that require a collection scan and will return an error. Exclusions include queries without filters and queries against capped collections, such as the oplog. [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]
Query settings have more functionality and are preferred over deprecated index filters. [source]
Index errors found during the collection scan phase, except duplicate key errors, are returned immediately and then the index build stops. Earlier MongoDB versions return errors in the commit phase, which occurs near the end of the index build. MongoDB 7.1 helps you to rapidly diagnose index errors. For example, if an incompatible index value format is found, the error is returned to you immediately. [source]
| Output Field | Description | | --- | --- | | `name` | Index name. | | [key](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#std-label-indexStats-output-key) | Index key specification. See also: [spec.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#std-label-indexStats-output-spec) | | [host](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#std-label-indexStats-output-host) | The hostname and port of the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-b [source]
| Metrics | Deployment metrics provide insight into hardware performance and database operation efficiency. Atlas collects metrics for your servers, databases, and MongoDB processes and stores metrics data at [various granularity levels](https://www.mongodb.com/docs/atlas/monitor-cluster-metrics/#premium-monitoring-granularity). For each granularity level, Atlas computes metrics as averages of the reported metrics at the next finer granularity level. Many metrics have a burst reporting equivalent. You can monitor metrics in the Atlas UI using the Metrics view, Real-Time Performance Panel, Quer [source]
The Query Profiler identifies slow queries and bottlenecks, and suggests index refinement and query restructuring to improve the performance of your database. It provides visibility into the slowest operations over up to seven days in the Atlas UI, making it easier to identify trends and outliers in query efficiency. We recommend that you use this data to pinpoint and troubleshoot poorly performing queries, reducing performance overhead. [source]
The Performance Advisor automatically analyzes logs for slow-running queries and recommends indexes to create and drop. It analyzes slow queries and provides index suggestions for individual collections, ranked by a calculated impact score, and tailored to your workload. This gives you an easy, instantaneous way to make high-impact performance improvements. We recommend that you monitor regularly, focus on slow queries, and enable the profiler selectively to minimize overhead. [source]
- You cannot specify [`db.collection.dropIndex("*")`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) to drop all non-`_id` indexes. Use [`db.collection.dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindexes.md#mongodb-method-db.collection.dropIndexes) instead. [source]
| Parameter | Type | Description | | --- | --- | --- | | `index` | string or document | Required. Specifies the index to drop. You can specify the index either by the index name or by the index specification document. To drop a [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text.md#std-label-index-type-text) index, specify the index name. You cannot specify `"*"` to drop all non-`_id` indexes. Use [`db.collection.dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindexes.md#mongodb-method-db.collection.dropIndexes) instead. If an i [source]
You can use [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) to drop existing indexes on the same collection even if there is a build in progress on another index. In earlier versions, attempting to drop a different index during an in-progress index build results in a `BackgroundOperationInProgressForNamespace` error. [source]
Starting in MongoDB 6.0, [`dropIndexes`](https://www.mongodb.com/docs/manual/reference/command/dropindexes.md#mongodb-dbcommand-dbcmd.dropIndexes) raises an error if you attempt to use it to remove the last remaining shard key compatible index. Passing `"*"` to [`dropIndexes`](https://www.mongodb.com/docs/manual/reference/command/dropindexes.md#mongodb-dbcommand-dbcmd.dropIndexes) drops all indexes except the `_id` index and the last remaining shard key compatible index, if one exists. [source]
If you restart the `mongod` as a standalone (that is, removing or commenting out [`replication.replSetName`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-replication.replSetName) or omitting [`--replSetName`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--replSet)), the `mongod` cannot restart the index build. The build remains in a paused state until it is manually [`dropped`.](https://www.mongodb.com/docs/manual/reference/command/dropindexes.md#mongodb-dbcommand-dbcmd.dropIndexes) [source]
| Stage | Description | | --- | --- | | Lock | The `mongod` obtains an exclusive `X` lock on the the collection being indexed. This blocks all read and write operations on the collection, including the application of any replicated write operations or metadata commands that target the collection. The `mongod` does not yield this lock. | | Initialization | The `mongod` creates three data structures at this initial state: The initial index metadata entry.; A temporary table ("side writes table") that stores keys generated from writes to the collection being indexed during the build process.; A t [source]
[`hasSortStage`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.hasSortStage) is a boolean that is `true` when a query **cannot** use the ordering in the index to return the requested sorted results; i.e. MongoDB must sort the documents after it receives the documents from a cursor. The field only appears when the value is `true`. [source]
WARNING: The accesses field reports index usage metrics only for the node where the query runs. For more comprehensive index usage statistics, run $indexStats on each node in the cluster. [source]
| Name | Type | Required | Description | | --- | --- | --- | --- | | --duration | int | false | Length of time in milliseconds for which you want to return results. If you specify the since option, the duration starts at the date and time specified. If you don't set the since option, this command returns data from the duration before the current time. | | -h, --help | | false | help for list | | --nLog | int | false | Maximum number of log lines to return. This value defaults to 20000. | | --namespaces | strings | false | Namespaces from which to retrieve suggested slow query logs formatted a [source]
Slow operations are logged based on `workingMillis`, which is the amount of time that MongoDB spends working on that operation. This means that factors such as waiting for locks and flow control do not affect whether an operation exceeds the slow operation threshold. [source]
When [`logLevel`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.logLevel) is set to `0`, MongoDB records *slow* operations to the diagnostic log at a rate determined by [`slowOpSampleRate`.](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-operationProfiling.slowOpSampleRate) [source]
At higher `logLevel` settings, all operations appear in the diagnostic log regardless of their latency with the following exception: the logging of slow oplog entry messages by the secondaries. The secondaries log only the slow oplog entries; increasing the `logLevel` does not log all oplog entries. [source]
The slow operation time threshold for an in-progress query, in milliseconds. MongoDB logs operations that run for longer than this threshold as slow in-progess queries. MongoDB logs a query as a slow in-progress query as soon as the query operation crosses the time threshold. [source]
The fraction of *slow* operations that should be profiled or logged. [`--slowOpSampleRate`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--slowOpSampleRate) accepts values between 0 and 1, inclusive. [source]
[`--slowOpSampleRate`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--slowOpSampleRate) does not affect the slow oplog entry logging by the secondary members of a replica set. Secondary members log all oplog entries that take longer than the slow operation threshold regardless of the [`--slowOpSampleRate`.](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--slowOpSampleRate) [source]
| Field | Type | Literal or Normalized | | --- | --- | --- | | `key.queryShape.filter` | Document | Normalized | | `key.queryShape.sort` | Document | Literal | | `key.queryShape.projection` | Document | Normalized | | `key.queryShape.skip` | Integer | Normalized | | `key.queryShape.limit` | Integer | Normalized | | `key.queryShape.singleBatch` | Boolean | Literal | | `key.queryShape.max` | Document | Normalized | | `key.queryShape.min` | Document | Normalized | | `key.queryShape.returnKey` | Boolean | Literal | | `key.queryShape.showRecordId` | Boolean | Literal | | `key.queryShape.tailable` | [source]
| Field | Type | Literal or Normalized | | --- | --- | --- | | `key.queryShape.collation` | Document | Normalized | | `key.queryShape.query` | Document | Normalized | | `key.queryShape.limit` | Integer | Normalized | | `key.queryShape.skip` | Integer | Normalized | [source]
`key.queryShape.limit` reflects the `limit` field of the delete statement, where `0` deletes all matching documents and `1` deletes a single document. It does not cap the number of query stats entries. [source]
| Field | Type | Literal or Normalized | | --- | --- | --- | | `key.queryShape.q` | Document | Normalized | | `key.queryShape.limit` | Integer | Literal | | `key.queryShape.let` | Document | Normalized | | `key.queryShape.collation` | Document | Literal | [source]
- Operation Execution Time (`millis`): Query time in milliseconds. This is the primary indicator of a slow query. If this metric is consistently high, consider optimizing the query logic, batching results, or rethink how the data is being accessed. [source]
- Response Length: Unusually large response lengths indicate that queries are returning more data than necessary. Consider using [projections](https://www.mongodb.com/docs/manual/tutorial/project-fields-from-query-results.md#std-label-projections) to limit the fields returned. [source]
$queryStats must run on the admin database as the first pipeline stage, cannot target a single collection, and needs the queryStatsRead privilege (queryStatsReadTransformed too when using transformIdentifiers); clusterMonitor grants both. [source]
Historical bugs: $queryStats on mongos could fail if the stats store did not fit in memory because the sort could not spill (SERVER-93832, fixed 8.0.4/8.1.0-rc0); memory mis-accounting in the store was fixed in 7.3.0-rc0 (SERVER-84298). [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]
- You cannot return the supported operation's query plan using `explain` or similar commands. [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]
Prior to MongoDB 7.0, [`$natural`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-operator-metaOp.-natural) accepts incorrect type values, such as `0`, `NaN`, "X", and `-0.01`. After MongoDB 7.0, if you pass any value other than `1` and `-1` to [`$natural`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-operator-metaOp.-natural), MongoDB returns an error. [source]
- Queries with `$text` cannot use [`$natural`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-operator-metaOp.-natural) sort. [source]
This endpoint only returns query shapes with REJECTED status. If the specified query shape hash does not correspond to a rejected query shape, a 404 Not Found error is returned. [source]
- [profiler log messages](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) and [diagnostic log messages (i.e. mongod/mongos log messages)](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-ref) when logging slow queries. [source]
These operations are also included in the logging of slow queries. See slowOpThresholdMs for more information about slow query logging. [source]
You can monitor operation-level query execution metrics for [query shapes](https://www.mongodb.com/docs/manual/core/query-shapes/) with slow-running queries using Query Shape Insights. The Query Shape Insights page displays charts and a table that describe the performance metrics for the query shapes in your project with the highest total execution time. You can filter the displayed query shape data by host, shard, and time range, and select up to five query shapes to visualize in the corresponding metric charts. [source]
Query Shape Insights displays charts and a table that describe metrics for query shapes in your project with slow-running queries. [source]
Atlas can send you a Query Shape Report email that summarizes inefficient query shapes for a cluster in your project. To help you identify and investigate slow queries, the report links directly to the Query Shape Insights page. [source]
Some high-latency [`$lookup`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup.md#mongodb-pipeline-pipe.-lookup) operations may not generate a slow query log for the foreign collection. This can occur because slow query logs correspond with operations that are reported in the [database profiler](https://www.mongodb.com/docs/manual/reference/database-profiler.md#std-label-profiler), whereas latency metrics increment only when a [collection lock](https://www.mongodb.com/docs/manual/faq/concurrency.md#std-label-faq-concurrency-locking) is acquired. [source]
If the `$lookup` query on a shard can perform a local read, the `$lookup` doesn't record a separate operation for querying the foreign collection. A local read refers to when the query on the foreign collection targets only the same shard where the current operation is being executed. As a result, the `$lookup` operation increases the `$collStats` latency metrics and operation counts, but does not generate a slow query log for the foreign collection. [source]
To change the per-operation limit, set the [`internalQueryMaxMemoryUsageBytesPerOperation`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.internalQueryMaxMemoryUsageBytesPerOperation) parameter at startup, at runtime, or with query settings. [source]
For a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instance, the command enables, disables, or configures the [database profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler). The profiler captures and records data on the performance of write operations, cursors, and database commands on a running [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instance. If the profiler is disabled, the command configures how slow operations [source]
For a [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instance, the command only configures how operations get written to the diagnostic log. You cannot enable the [database profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) on a [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instance because `mongos` does not have any collections that the profiler can write to. [source]
| Field | Type | Description | | --- | --- | --- | | `profile` | int | Configures the profiler level. The following profiler levels are available: `0`The profiler is off and does not collect any data. This is the default profiler level.`1`The profiler collects data for operations that exceed the `slowms` threshold or match a specified [filter.](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-options-filter)When a filter is set:The `slowms` and `sampleRate` options are not used for profiling.; The profiler only captures operations that [source]
With [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instances, the method sets the `slowms`, `sampleRate` and `filter` configuration settings, which configure how operations get written to the diagnostic log. You cannot enable the [Database Profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md) on a [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instance because `mongos` does not have any collections that the profiler can write to. The `profile` level m [source]
| Log Message | Description | | --- | --- | | Accepted TLS connection from peer | Indicates that the server successfully parsed the peer certificate during the TLS handshake with an accepted ingress connection. | | Ingress TLS handshake complete | Indicates that the TLS handshake with an ingress connection is complete. | | Hello completed | Indicates that the initial connection handshake completed on an incoming client connection. MongoDB displays the log message only with the first `hello` command. | | Auth metrics report | Specifies the completion of a step in the authentication conversation [source]
In rare circumstances, a write can fail due to cache pressure. When this happens MongoDB issues a `TemporarilyUnavailable` error and increments the `temporarilyUnavailableErrors` counter in two places: the slow query log and the [Full Time Diagnostic Data Capture (FTDC).](https://www.mongodb.com/docs/manual/administration/full-time-diagnostic-data-capture.md#std-label-ftdc-stub) [source]
- [atlas api performanceAdvisor listSlowQueryLogs](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-api-performanceadvisor-listslowquerylogs.md#std-label-atlas-api-performanceAdvisor-listSlowQueryLogs) - Returns log lines for slow queries that the Performance Advisor and Query Profiler identified. [source]
The slow operation threshold determines which operations are flagged by the Performance Advisor and Query Profiler. When enabled, the application uses the average execution time for operations on your cluster to determine slow-running queries. As a result, the threshold is more pertinent to your cluster workload. Application-managed slow operation threshold is enabled by default for dedicated clusters (M10+). [source]
Returns log lines for slow queries that the Performance Advisor and Query Profiler identified. [source]
| Name | Type | Required | Description | | --- | --- | --- | --- | | --duration | int | false | Length of time expressed during which the query finds slow queries among the managed namespaces in the cluster. This parameter expresses its value in milliseconds. If you don't specify the **since** parameter, the endpoint returns data covering the duration before the current time.; If you specify neither the **duration** nor **since** parameters, the endpoint returns data from the previous 24 hours. | | --envelope | envelope | false | Flag that indicates whether Application wraps the response in an [source]
If the mongod encounters a key generation error while generating a key during the collection scan, it stores that key in the constraint violation table for later processing. [source]
You can return log lines for slow queries that the Query Profiler identifies from the Atlas Administration API with [Return Slow Queries.](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-listslowqueries) [source]
[Query Shape Insights](https://www.mongodb.com/docs/atlas/query-shape-insights.md#std-label-query-shape-insights) displays performance statistics for query shapes with slow-running queries. You can select up to five query shapes to view their metrics in charts, and filter by host, shard, and time range to monitor the most relevant performance metrics and statistics for your project. [source]
The [Query Profiler](https://www.mongodb.com/docs/atlas/tutorial/query-profiler.md#std-label-query-profiler) displays slow-running operations and their key performance statistics. You can explore a sample of historical queries for up to the last seven days without additional cost or performance overhead. Before you enable the Query Profiler, see [Considerations.](https://www.mongodb.com/docs/atlas/tutorial/query-profiler.md#std-label-atlas-considerations-profile-database) [source]
Collection scans indicate that the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) had to scan the entire collection document by document to identify the results. This is a generally expensive operation and can result in slow queries. [source]
Collection scans indicate that the mongod had to scan the entire collection document by document to identify the results. This is a generally expensive operation and can result in slow queries. [source]
- In general, you should use [`$where`](https://www.mongodb.com/docs/manual/reference/operator/query/where.md#mongodb-query-op.-where) only when you cannot express your query using another operator. If you must use [`$where`](https://www.mongodb.com/docs/manual/reference/operator/query/where.md#mongodb-query-op.-where), try to include at least one other standard query operator to filter the result set. Using [`$where`](https://www.mongodb.com/docs/manual/reference/operator/query/where.md#mongodb-query-op.-where) alone requires a collection scan. [source]
The profiler does not capture slow oplog entries. [source]
You cannot run $queryStats on a specific collection. For complete examples, see Examples. [source]
Statistics for the $queryStats stage are tracked in a virtual collection that is stored in-memory. The memory limit for the virtual collection is 1% of the system's total memory. [source]
Pattern names describe plans at a coarse level. They omit limit and skip stages, and they don't distinguish whether a stage applies a filter or which type of projection a plan uses. To determine those details, combine a pattern counter with the nodes counters and the query shape for the entry. [source]
Sort stages, counted separately by sort type and by whether the sort has a limit. [source]
The slow operation threshold determines which operations are flagged by the Performance Advisor and Query Profiler. When disabled, the application considers any operation that takes longer than 100 milliseconds to be slow. [source]
You cannot run `$queryStats` on a specific collection. For complete examples, see [Examples.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#std-label-queryStats-examples) [source]
These operations are also included in the logging of slow queries. See [`slowOpThresholdMs`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-operationProfiling.slowOpThresholdMs) for more information about slow query logging. [source]
The threshold determines which operations the Performance Advisor and Query Profiler considers slow. When enabled, MongoDB Cloud uses the average execution time for operations on your cluster to determine slow-running queries. As a result, the threshold is more pertinent to your cluster workload. The slow operation threshold is enabled by default for dedicated clusters (M10+). When disabled, MongoDB Cloud considers any operation that takes longer than 100 milliseconds to be slow. [source]
The length in bytes of the operation's result document. A large [`responseLength`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.responseLength) can affect performance. To limit the size of the result document for a query operation, you can use any of the following: [source]
| Notification Option | Description | | --- | --- | | Atlas Project | Sends the alert by email or text message to users with specific roles in the Project. Atlas Project is the default alert recipient. You can configure the roles the alert is sent to and how it's delivered. You can't add a second Atlas Project as the recipient. If the [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) role is assigned to a human project member, Atlas delivers alerts to that member's configured email address or SMS target. If the [`Project Owner`](https: [source]
| Notification Option | Service Account Alerts | User Alerts | Billing Alerts | Description | | --- | --- | --- | --- | --- | | Atlas Organization | | | | Sends the alert by email or text message to users with specific roles in the Organization. Select the Organization roles that should receive the alerts from the Select Role(s) check boxes or select All Roles for all users in the Organization to receive the alert.; Select SMS to send these alerts to the mobile number configured for each Atlas Organization user in their Account page.; Select Email to send these alerts to the email address c [source]
Slow operation log messages and database profiler entries include a cpuNanos field that specifies the total CPU time spent by a query operation in nanoseconds. The cpuNanos field is only available on Linux systems. [source]
The totalOplogSlotDurationMicros in the slow query log message shows the time between a write operation getting a commit timestamp to commit the storage engine writes and actually committing. mongod supports parallel writes. However, it commits write operations with commit timestamps in any order. [source]
MongoDB 8.3 also introduces slow in-progress query log entries. Queries trigger a slow-in progress log during execution. These logs contain less information than standard slow query logs. MongoDB logs queries at most once if the query's duration surpasses the operationProfiling.slowOpInProgressThresholdMs. [source]
When an operation specifies a time limit for a query, slow query logs contain a deadline field. deadline indicates the time the operation must complete by, which is equal to the time at the start of the operation plus the value of the query timeout. [source]
Starting in MongoDB 5.0, log messages for slow queries include a system.profile.authorization section. These metrics help determine if a request is delayed because of contention for the user authorization cache. [source]
MongoDB automatically selects the engine to execute the query. In MongoDB versions earlier than 8.0, you cannot manually specify an engine for a particular query. Starting in MongoDB 8.0, you can use query settings to specify an engine for queries. For details, see [`setQuerySettings`.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) [source]
The [profiler entries](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) and the [diagnostic log messages (i.e. mongod/mongos logmessages)](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) for read/write operations include: [source]
The CRUD operations below are omitted from the [slow operations](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) query log and the [Database Profiler](https://www.mongodb.com/docs/manual/reference/database-profiler.md#std-label-profiler) `system.profile` collection when you run them on an encrypted collection. [source]
The Query Profiler diagnoses and monitors performance issues. This monitoring can expose slow-running queries and their key performance statistics in the Atlas UI. [source]
Atlas collects and displays statistics from any of your [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instances. The Query Profiler stores your `mongod` query [log data](https://www.mongodb.com/docs/atlas/mongodb-logs.md#std-label-mongodb-logs), which can be accessed directly through the Query Profiler or through the Atlas CLI, and use it to identify slow queries. Atlas displays this data on the Query Insights page, in the Query Profiler tab of an instance. [source]
The Atlas Query Profiler shows operations across your entire cluster by default. You can filter the Query Profiler view to only operations coming from specified hosts with the Filter by Hosts dropdown, which allows you to view data related to one or more specific hosts or to view primary or secondary host groups. The Query Insights option in the Cluster sidebar displays information to reveal slow database operations over a set time frame, such as the following: [source]
Atlas manages the threshold for slow operations for each `mongod` host based on average operation execution time on that host. This threshold can be changed using the [`db.setProfilingLevel`](https://www.mongodb.com/docs/manual/reference/method/db.setProfilingLevel.md#mongodb-method-db.setProfilingLevel) [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) command. [source]
Changing the threshold for slow operations using [`db.setProfilingLevel`](https://www.mongodb.com/docs/manual/reference/method/db.setProfilingLevel.md#mongodb-method-db.setProfilingLevel) can impact performance and system log settings. Carefully consider any performance and security implications before you use [`db.setProfilingLevel`](https://www.mongodb.com/docs/manual/reference/method/db.setProfilingLevel.md#mongodb-method-db.setProfilingLevel) to adjust the Query Profiler settings on a production deployment. Query Profiler settings reset to default values following a node restart. [source]
The following section describes how to find slow queries using the Query Profiler. [source]
The Query Profiler uses a scatterplot chart and a table directly below the chart to help you find slow operations. [source]
Changing the threshold for slow operations using db.setProfilingLevel can impact performance and system log settings. Carefully consider any performance and security implications before you use db.setProfilingLevel to adjust the Query Profiler settings on a production deployment. Query Profiler settings reset to default values following a node restart. [source]
Some high-latency $lookup operations don't generate a slow query log for the foreign collection. This can occur because slow query logs correspond with operations that are reported in the Query Profiler, whereas latency metrics increment only when a collection lock is acquired. [source]
Find Slow Queries with the Query Profiler [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]
| Field | Type | Description | | --- | --- | --- | | `planCacheSetFilter` | string | The name of the collection for the index filter. | | `query` | document | The query predicate for the index filter. Only the predicate structure, including the field names, is used in the index filter. The field values in the query predicate are not used. Therefore, the query predicate in an index filter is used by similar queries that differ only in the field values. | | `sort` | document | Optional. The sort for the index filter. | | `projection` | document | Optional. The projection for the index filter. | [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]
| Field | Type | Description | | --- | --- | --- | | `find` | string | The name of the collection or [view](https://www.mongodb.com/docs/manual/core/views.md#std-label-views-landing-page) to query. | | `filter` | document | Optional. The query predicate. If unspecified, all documents in the collection match the predicate. | | [sort](https://www.mongodb.com/docs/manual/reference/command/find.md#std-label-find-cmd-sort) | document | Optional. The sort specification for the ordering of the results. | | `projection` | document | Optional. The [projection specification](https://www.mongodb.com/docs [source]
Starting in MongoDB 8.0, use query settings instead of adding [index filters](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters). Index filters are deprecated starting in MongoDB 8.0. [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]
| State | Description | | --- | --- | | [Missing](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-cache-entry-missing) | No entry for this shape exists in the cache. For a query, if the cache entry state for a plan cache query shape is [Missing:](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-cache-entry-missing) Candidate plans are evaluated and a winning plan is selected.; The cache creates an entry for the plan cache query shape in state [Inactive](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-cache-entry-inactive) with a value that q [source]
Query knobs are part of the hashed query settings, so they are also part of the [plan cache key](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-plan-cache-key). If you change a knob value, MongoDB produces a new plan cache key, so the planner creates a fresh plan instead of reusing a stale cached plan. [source]
Prior to MongoDB 6.0.7, if a [secondary index](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-secondary-index) existed on a clustered collection and the secondary index was usable by your query, the query planner selected the secondary index instead of the clustered index by default. In MongoDB 6.1 and prior, to use the clustered index, you must provide a hint because the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) does not automatically select the clustered index. [source]
| Field | Type | Description | | --- | --- | --- | | dropIndexes | String | The name of the collection whose indexes to drop. | | index | string or document or array of strings | The index or indexes to drop. To drop all indexes except the `_id` index and the last remaining shard key index from the collection if one exists, specify `"*"`.; To drop a single index, specify either the index name, the index specification document (unless the index is a [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text.md#std-label-index-type-text) index), or an array of the index name. [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]
Unlike `planCacheShapeHash`, `planCacheKey` is a function of both the query shape and the currently available indexes for the shape. That is, if indexes that can support the query shape are added/dropped, the `planCacheKey` value may change whereas the `planCacheShapeHash` value would not change. [source]
Starting in MongoDB 8.0, add query settings for query shapes instead of index filters for collections. Index filters are deprecated starting in MongoDB 8.0. Query settings have more functionality than index filters, and index filters aren't persistent after cluster shutdown. [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]
If the slow query log contains consecutive [`$match`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/match.md#mongodb-pipeline-pipe.-match) stages in the aggregation pipeline, the two stages can [coalesce](https://www.mongodb.com/docs/manual/core/aggregation-pipeline-optimization/#-match----match-coalescence) into the first [`$match`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/match.md#mongodb-pipeline-pipe.-match) stage and result in a single [`$match`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/match.md#mongodb-pipeline-pipe [source]
If the slow query log contains consecutive $match stages in the aggregation pipeline, the two stages can coalesce into the first $match stage and result in a single $match stage. As a result, the query shape in the Performance Advisor might differ from the actual query you ran. [source]
Number of times a collection scan occurred during query execution. During a collection scan, each document in a collection is compared to the query predicate. Collection scans occur if no appropriate [index](https://www.mongodb.com/docs/manual/indexes.md#std-label-indexes) exists that [covers](https://www.mongodb.com/docs/manual/core/query-optimization.md#std-label-indexes-covered-queries) the query. [source]
If one of the two boundaries is not specified, the query plan will be an index scan that is unbounded on one side. This may degrade performance compared to a query containing neither operator, or one that uses both operators to more tightly constrain the index scan. [source]
| Parameter | Type | Description | | --- | --- | --- | | `unique` | boolean | Optional. Creates a unique index so that the collection 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-index-hashed-index) | | `name` | string | Optional. The name of the index. If unspecified, MongoDB generates an index name by concatenating the [source]
By hiding an index from the planner, you can evaluate the potential impact of dropping an index without actually dropping the index. If the impact is negative, you can unhide the index instead of having to recreate a dropped index. And because indexes are fully maintained while hidden, the indexes are immediately available for use once unhidden. [source]
A 1:1 docs-examined to returned ratio does not prove an index is cheap. Pythian's index {certificate_number, address.zip, date} had docs examined equal to returned but over 40k keys examined, and execution time rose 10% versus no index, because the range field came first and the zip filter ran after the fetch. [source]
| Chart/Location | Description | | --- | --- | | Connections, Network In, Network Out (Top of panel) | Displays the number of current connections to the machine hosting MongoDB and the number of inbound and outbound bytes as reported by [`mongostat`.](https://www.mongodb.com/docs/database-tools/mongostat.md#mongodb-binary-bin.mongostat) | | CPU, Disk IOPS, and Sys Mem (Top of panel) | Displays the currently used percentage of CPU, disk read and write operations per second, and the total physical memory usage, excluding buffers and swap space, of the machine hosting MongoDB. | | Operations | Di [source]
MongoDB does not create an index on the `_id` field when you create a time series collection. This differs from regular collections which have an index on the `_id` field by default. Commands that specify a hint on the `_id` field on time series collections return an error unless you manually create an index on the `_id` field. [source]
Hinting a hidden index or an index that does not exist returns an error rather than being ignored; the server error text is 'bad hint'. [source]
Given these queries, the index with the [partial filter expression](https://www.mongodb.com/docs/manual/core/index-partial.md#std-label-partial-index-query-coverage) can support query operation 2 but *not* support query operation 1. Since the indexes available to support query operation 1 differs from query operation 2, the two queries have different `planCacheKey`. [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]
| Behavior Starting in MongoDB 7.1 | Behavior in Earlier MongoDB Versions | | --- | --- | | Index errors found during the collection scan phase, except duplicate key errors, are returned immediately and then the index build stops. Earlier MongoDB versions return errors in the commit phase, which occurs near the end of the index build. MongoDB 7.1 helps you to rapidly diagnose index errors. For example, if an incompatible index value format is found, the error is returned to you immediately. | Index build errors can take a long time to be returned compared to MongoDB 7.1 because the errors are [source]
Starting in MongoDB 8.3, [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) is idempotent. If you specify an index that does not exist, [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) ignores the non-existent index and completes successfully instead of returning an `IndexNotFound` error. In earlier versions, [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.col [source]
The docs state queryShapeHash is derived from the shape itself and is expected to be identical on every node and on replica sets vs sharded clusters in current versions, but advise verifying before reusing it across clusters, versions or after migration. [source]
Starting in MongoDB 9.0, you can use the `queryKnobs` setting to override internal server parameters for a single [query shape](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) instead of the whole instance. Set the `queryKnobs` field for targeted queries to mitigate the impact of one regressed shape without changing behavior for other workloads on the same deployment. [source]
For example, you can override the [`notablescan`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.notablescan) server parameter for a single query shape instead of the whole instance by setting `queryKnobs` to `{ noTableScan: true }`. [source]
Unlike [`setParameter`](https://www.mongodb.com/docs/manual/reference/command/setparameter.md#mongodb-dbcommand-dbcmd.setParameter), which applies per process and can differ between nodes, MongoDB applies the same `queryKnobs` values across the whole cluster for the matching query shape. [source]
- The Atlas [Query Profiler](https://www.mongodb.com/docs/atlas/tutorial/query-profiler.md#std-label-query-profiler) records operations that Atlas considers slow when compared to average execution time for all operations on your cluster. [source]
Applications may target different members of a replica set. As such, each replica set member might receive different read commands and have plan cache information that differs from other members. Nevertheless, running `$planCacheStats` on a replica set or a sharded cluster obeys the normal read preference rules. That is, on a replica set, the operation gathers plan cache information from just one member of replica set, and on a sharded cluster, the operation gathers plan cache information from just one member of each shard replica set. [source]
The Query Profiler differs from the [Database Profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler/). The Query Profiler identifies specific inefficient queries based on entries from your `mongod` logs. The Database Profiler returns detailed information about commands executed on the `mongod` based on the specified [profiling level](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler/#profiling-levels). Changing the profiling level doesn't impact the slow queries displayed in the Query Profiler. [source]
| Field | Type | Description | | --- | --- | --- | | `resumeAfter` | document | Optional. Directs [`watch()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.watch.md#mongodb-method-db.collection.watch) to attempt resuming notifications starting after the operation specified in the resume token. Each change stream event document includes a resume token as the `_id` field. Pass the *entire* `_id` field of the change event document that represents the operation you want to resume after. `resumeAfter` is mutually exclusive with `startAfter` and `startAtOperationTime`. | | `star [source]
The Atlas Query Profiler records operations that Atlas considers slow when compared to average execution time for all operations on your cluster. [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]
Atlas Query Shape Insights (M10+, MongoDB 8.0+) ranks shapes by total execution time, filterable by host/shard over 7 days; users without PII-viewing roles see only the queryShapeHash instead of the shape. [source]

Facts and statements

The following example creates an index filter on the `orders` collection such that for queries that consist only of an equality match on the `status` field without any projection and sort, the query optimizer evaluates only the two specified indexes and the collection scan for the winning plan: [source]
The [query optimizer](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-optimizer) uses query settings as an additional input during query planning. Index hints in query settings restrict the set of indexes available to the planner, but don't guarantee that the planner will use the index. The planner can still select a collection scan as the winning plan for a given query shape hash. [source]
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]
Index filters only affect which indexes the planner evaluates; the planner may still select the collection scan as the winning plan for a given 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]
Increasing the plan cache size adds more cached [plan cache query shapes](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) for the [query planner](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization). This can improve query performance, but increases memory usage. [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]
Index hints in query settings (indexHints.allowedIndexes: index name, key pattern or $natural) only restrict the indexes available to the planner; they do not guarantee use, and the planner can still pick a collection scan. [source]
The following examples create a collection and add query settings for different commands. For all executions of a query shape on the cluster, the examples restrict the query planner to either using the hinted index, or a collection scan. [source]
Lists the [index filters](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters) associated with [plan cache query shapes](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) for a collection. [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]
```javascript queryPlanner: { winningPlan: { stage: 'SINGLE_SHARD', shards: [ { explainVersion: '1', ... namespace: 'test.pizzaOrders', indexFilterSet: false, parsedQuery: { orderDate: { '$gt': ISODate('2023-01-20T00:00:00.000Z') } }, querySettings: { indexHints: { ns: { db: 'test', coll: 'pizzaOrders' }, allowedIndexes: [ 'orderDate_1' ] }, queryFramework: 'classic', comment: 'Index hint for orderDate_1 index to improve query performance' }, ... } ... ] } } ``` [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]
Starting in MongoDB 6.0, an index filter uses the [collation](https://www.mongodb.com/docs/manual/reference/collation.md#std-label-collation) previously set using the [`planCacheSetFilter`](https://www.mongodb.com/docs/manual/reference/command/plancachesetfilter.md#mongodb-dbcommand-dbcmd.planCacheSetFilter) command. [source]
The following example creates an index filter for the `orders` collection. The filter applies to queries whose predicate is an equality match on the `item` field, where only the `quantity` field is projected and an ascending sort by `order_date` is specified. [source]
The following example creates an index filter for the `orders` collection. The filter applies to queries whose predicate is an equality match on the `item` field and the collation `en_US` (English United States). [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]
You can use query settings to add index hints, define [operation rejection filters](https://www.mongodb.com/docs/manual/tutorial/operation-rejection-filters.md#std-label-operation-rejection-filters), and set other fields for all executions of a given [query shape](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) on a cluster. A cluster's query settings persist across restarts. [source]
You can use query settings to set index hints, set operation rejection filters, and other fields. The settings apply to the query shape on the entire cluster. The cluster retains the settings after shutdown. [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]
Specify the [plan cache query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) to remove a specific index filter. Omit the plan cache query shape to clear all index filters on a collection. [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]
Number of slot-based execution engine query plans found in the query cache and reused to avoid the query planning phase. [source]
Number of slot-based execution engine query plans that were discarded and re-optimized. [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]
Both ranking mechanisms store the chosen plan in the **query plan cache** and reuse it for subsequent queries with the same [plan cache query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape). The rest of this page describes plan cache behavior and related concepts that apply to both mechanisms. [source]
queryPlanner.winningPlan.stage displays COLLSCAN to indicate a collection scan. [source]
Removes cached query plans for a collection. Specify a [plan cache query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) to remove cached query plans for that shape. Omit the plan cache query shape to clear all cached query plans. [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]
```javascript db.adminCommand( { setQuerySettings: { find: "pizzaOrders", filter: { orderDate: { $gt: ISODate( "2023-01-20T00:00:00Z" ) } }, sort: { totalNumber: 1 }, $db: "test" }, settings: { indexHints: { ns: { db: "test", coll: "pizzaOrders" }, allowedIndexes: [ "orderDate_1" ] }, queryFramework: "classic", comment: "Index hint for orderDate_1 index to improve query performance" } } ) ``` [source]
```javascript [ { queryShapeHash: 'AB8ECADEE8F0EB0F447A30744EB4813AE7E0BFEF523B0870CA10FCBC87F5D8F1', settings: { indexHints: [ { ns: { db: 'test', coll: 'pizzaOrders' }, allowedIndexes: [ 'orderDate_1' ] } ], queryFramework: 'classic', comment: 'Index hint for orderDate_1 index to improve query performance' }, representativeQuery: { find: 'pizzaOrders', filter: { orderDate: { '$gt': ISODate('2023-01-20T00:00:00.000Z') } }, sort: { totalNumber: 1 }, '$db': 'test' } } ] ``` [source]
```javascript db.adminCommand( { setQuerySettings: { distinct: "pizzaOrders", key: "totalNumber", query: { totalNumber: 10, orderDate :{ '$gt': ISODate('2023-01-20T00:00:00.000Z') } } , $db: "test" }, settings: { indexHints: { ns: { db: "test", coll: "pizzaOrders" }, allowedIndexes: [ "orderDate_1" ] }, queryFramework: "classic", comment: "Index hint for orderDate_1 index to improve query performance" } } ) ``` [source]
```javascript db.adminCommand( { setQuerySettings: { aggregate: "pizzaOrders", pipeline: [ { $match: { totalNumber: 10, orderDate :{ '$gt': ISODate('2023-01-20T00:00:00.000Z') } } }, { $group: { _id: "$type", totalMediumPizzaOrdersGroupedByType: { $sum: "$totalNumber" } } } ], $db: "test" }, settings: { indexHints: { ns: { db: "test", coll: "pizzaOrders" }, allowedIndexes: [ "totalNumber_1" ] }, queryFramework: "classic", comment: "Index hint for totalNumber_1 index to improve query performance" } } ) ``` [source]
"planSummary" : "COLLSCAN", [source]
Sets the size of the [plan cache](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-read-operations-query-optimization) only for the [slot-based query execution engine.](https://www.mongodb.com/docs/manual/reference/sbe.md#std-label-sbe-landing) [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]
cursor.hint() overrides MongoDB's default index selection and query optimization; the index is given by name or key specification document, or {$natural: 1} / {$natural: -1} forces a forward or reverse collection scan. [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]
- Any DDL event clears the plan cache for the relevant collection. Example DDL events include dropping a collection, and creating, deleting, or hiding an index. [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]
For the plan cache query shape, the query optimizer will only consider indexed plans which use the index `{ item: 1, order_date: 1, quantity: 1 }`. [source]
For the plan cache query shape, the query optimizer only uses indexed plans that use the index `{ item: 1, order_date: 1, quantity: 1 }`. [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]
A hinted query skips plan-cache trial and is planned directly from the hinted index (stated by one MongoDB author; not confirmed in official docs). [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]
Verify applied settings via explain: queryPlanner output includes a querySettings block (indexHints, queryFramework, comment) and indexFilterSet:false; $querySettings with showDebugQueryShape:true also returns debugQueryShape for the shape. [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]
This metric **does not** reflect the MongoDB Search index usage. [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]
Winning plans that don't use a collection scan, an index scan, a count scan, a distinct scan, or a geospatial access path. A plan that only performs a text search increments both textMatch and otherAccessPath. [source]
[Index Filters](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters) can affect the choice of index used. See [Index Filters](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-index-filters) for details. [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]
| Field | Type | Description | | --- | --- | --- | | `planCacheListFilters` | string | The name of the collection. | | `comment` | any | Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations: [mongod log messages](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-ref), in the `attr.command.cursor.comment` field.; [Database profiler](https://www.mongodb.com/docs/manual/reference/database-profiler.md#std-label-profiler) output, in the [`command.comment`](https://w [source]
| Number of matching documents | Query plan | Result | | --- | --- | --- | | 0 | Any | The method returns `null` | | 1 | Any | The method returns the document that satisfies the specified query criteria. | | 2 or more | Collection Scan | The method returns the first document according to the [natural order](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-natural-order). In [capped collections](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-capped-collection), natural order is the same as insertion order. | | 2 or more | Index Scan | The method returns the [source]
- Manually clear the entire plan cache using the [`PlanCache.clear()`](https://www.mongodb.com/docs/manual/reference/method/plancache.clear.md#mongodb-method-PlanCache.clear) method. [source]
- Manually clear specific plan cache entries using the [`PlanCache.clearPlansByQuery()`](https://www.mongodb.com/docs/manual/reference/method/plancache.clearplansbyquery.md#mongodb-method-PlanCache.clearPlansByQuery) method. [source]
The estimated size in bytes of a `plan cache` entry is available in the output of [`$planCacheStats`.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/plancachestats.md#mongodb-pipeline-pipe.-planCacheStats) [source]
A hash of the key for the plan cache entry associated with the query. [source]
Number of classic execution engine query plans found in the query cache and reused to avoid the query planning phase. [source]
Number of classic execution engine query plans which were not found in the query cache and went through the query planning phase. [source]
Number of classic execution engine query plans that were discarded and re-optimized. [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]
- `planRankerMethod: "cbr"` indicates that the query planner chose the cost-based ranker. [source]
- `planRankerMethod: "mp"` indicates that the query planner chose the multi-planner. [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]
If you use `db.collection.countDocuments()` with an empty query filter, MongoDB performs a full collection scan which can be inefficient. To improve performance, this example specifies a [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) to use the automatically generated `_id` index. Alternatively, you can use a query filter that finds all documents such as `{ "_id": { $gte: MinKey } }` to count all documents using an index. [source]
The [query optimizer](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-optimizer) uses the query settings as an additional input during query planning, which affects the plan selected to run the query. You can also use query settings to block a query shape. [source]
The query optimizer uses the query settings as an additional input during query planning. The query settings affect the plan selected to run a query that has a matching query shape. [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]
| Field | Type | Literal or Normalized | | --- | --- | --- | | `key.queryShape.pipeline` | Array | Normalized | | `key.queryShape.explain` | Boolean | Literal | | `key.queryShape.allowDiskUse` | Boolean | Literal | | `key.queryShape.allowPartialResults` | Boolean | Literal | | `key.queryShape.collation` | Document | Literal | | `key.queryShape.hint` | String or Document | Normalized | | `key.queryShape.let` | Document | Normalized | [source]
A string that specifies whether the cursor uses a collection scan (`COLLSCAN`) or an index scan (`IXSCAN { ... }`). [source]
query settings, which you can add with setQuerySettings. (As you'll see later on this page, query settings specify indexes and execution settings for a query shape.) [source]
Query settings allow you to use an index for all executions of a query shape in a cluster. Also, to prevent an operation from causing excessive cluster workload, you can reject all operations associated with a query shape using an operation rejection filter. [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]
The array of indexes for the plan cache query shape. [source]
- query settings, which you can add with [`setQuerySettings`](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings). (As you'll see later on this page, query settings specify indexes and execution settings for a query shape.) [source]
You can provide an existing query shape hash string in `setQuerySettings` and an updated `settings` document with `indexHints` and other fields: [source]
In current supported versions, the same query shape is expected to produce the same query shape hash across nodes and deployment types. To learn how the hash behaves across nodes, deployment types, and clusters, see [Query Shape Hash Stability.](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shape-hash-stability) [source]
- Use a [`$querySettings`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querysettings.md#mongodb-pipeline-pipe.-querySettings) stage in an [aggregation pipeline](https://www.mongodb.com/docs/manual/core/aggregation-pipeline.md#std-label-aggregation-pipeline) and examine the `queryShapeHash` field. [source]
The settings apply to the [query shape](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#std-label-queryStats-queryShape) on the entire cluster. The cluster retains the settings after shutdown. [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]
- The same fields as 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. See the syntax sections on the pages for those commands for the fields you can include in `removeQuerySettings`. [source]
- Click View more details in the right-side panel to view the full query shape, detailed execution statistics, query log, and suggestions for improvement. [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]
Profiler level 0 is off, level 1 records operations slower than slowms (or matching a filter), and level 2 records all operations; at level 2 the profiler ignores user-supplied slowms and filter values. [source]
If a profiling filter is set, slowms and sampleRate no longer apply to the profiler or the diagnostic log. A filter such as { op: 'query', millis: { $gt: 2000 } } controls which operations are profiled and logged. [source]
MongoDB warns the profiler can degrade performance and disk use, especially at level 2 or with a low slowms at level 1, and points to Atlas Query Profiler / Performance Advisor as alternatives. Blogs advise level 1 with a tuned slowms and a lowered sampleRate on busy systems; avoid level 2 in production. [source]
Using `explain` ignores all existing plan cache entries and prevents the MongoDB query planner from creating a new plan cache entry. [source]
The query plan cache does not persist if a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) restarts or shuts down. In addition: [source]
Specifies the maximum data size that a collection scan reads. At planning time, MongoDB rejects a query if the query plan requires an unbounded collection scan on a collection whose uncompressed logical data size exceeds this threshold. MongoDB measures the threshold in uncompressed logical bytes, which is equivalent to the `size` field that the [`collStats`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-dbcommand-dbcmd.collStats) command returns, and not the compressed on-disk size. [source]
Finds the distinct values for a specified field across a single collection. Returns a document containing an array of distinct values and an embedded document containing query statistics and the query plan. [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]
A document that reports query plan cache statistics. [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]
Returns [plan cache](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) information for a collection. The stage returns a document for each plan cache entry. [source]
`explain` ignores the plan cache. Instead, a set of candidate plans are generated, and a winner is chosen without consulting the plan cache. Furthermore, `explain` prevents the MongoDB query planner from caching the winning plan. [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]
For more information about hints and query settings, see [Query Settings Syntax.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#std-label-setQuerySettings-syntax) [source]
You can specify `{ $natural : 1 }` to force the query to perform a forwards collection scan: [source]
You can also specify `{ $natural : -1 }` to force the query to perform a reverse collection scan: [source]
).hint( { year: 1, rated: 1 } ).explain("executionStats") [source]
).hint( { rated: 1, year: 1 } ).explain("executionStats") [source]
$queryStats groups similar queries together by normalizing user-provided field values to their data types. For example, a filter specified as { item: 'card' } is normalized to { item : '?string'}. $queryStats also normalizes the values of some query options like hint and comment. [source]
Although the `planCacheSize` parameter existed in prior versions of MongoDB, it had no effect on the plan cache until version 6.3. [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]
Number of slot-based execution engine plans which were not found in the query cache and went through the query planning phase. [source]
Number of times the server performed a replan operation for the slot-based execution engine that produced a plan identical to one already in the query cache. [source]
- `queryFramework: "classic"` indicates that the classic engine executed the query. [source]
- `queryFramework: "sbe"` indicates that the slot-based query execution engine executed the query. [source]
system.profile.keysExamined [source]
system.profile.docsExamined [source]
system.profile.queryShapeHash [source]
system.profile.planCacheShapeHash [source]
system.profile.planCacheKey [source]
system.profile.planSummary [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]
In MongoDB 8.0 and earlier versions, the existing plan cache query shape supports: [source]
the fields and operations also supported by the plan cache query shape. Examples: filter, sort, and projection. [source]
Starting in MongoDB 8.0, you can use a $querySettings pipeline stage to return query settings specified for each query shape. [source]
You can apply the same query settings to a query shape on every node in a deployment. Before you rely on query settings that you specify by query shape hash after a migration, such as from a replica set to a sharded cluster, or on a different cluster, verify that the hash still matches in the target deployment. [source]
MongoDB doesn't store these settings on the cluster, and they don't apply to other queries with the same query shape. To set query settings that persist for a query shape, use setQuerySettings. [source]
MongoDB combines the settings that you pass in the command with any query settings stored on the cluster for the same query shape. If both settings specify the same field, the stored cluster setting takes precedence. [source]
Prior to version 7.2, information on the number of plan cache query shapes was stored in the `query.planCacheTotalQueryShapes` field. [source]
The following aggregation pipeline uses [`$planCacheStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/plancachestats.md#mongodb-pipeline-pipe.-planCacheStats) followed by a [`$match`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/match.md#mongodb-pipeline-pipe.-match) stage to return specific information for a particular query hash: [source]
| Field | Type | Necessity | Description | | --- | --- | --- | --- | | `showDebugQueryShape` | boolean | Optional | If `true`, `$querySettings` returns a debugging version of the [query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-shape) output. You'll see an example in the next section. For output details, see [Query Shape.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#std-label-queryStats-queryShape) Default is `false`. | [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]
If a collection `orders` has the following plan cache query shape: [source]
- To add query settings for a query shape, use [`setQuerySettings`.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) [source]
If you provide a query shape to `removeQuerySettings`, include the fields for the existing query settings shape to delete. The field values don't have to match. For example, if you have existing query settings for `find x=1` and provide `find x=100` to `removeQuerySettings`, `removeQuerySettings` deletes the query settings for `find x=1`. [source]
In the following syntax, you provide a query shape hash string in `removeQuerySettings`: [source]
| Field | Type | Necessity | Description | | --- | --- | --- | --- | | `removeQuerySettings` | 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]
The following example uses `removeQuerySettings` to delete the query settings identified using `queryShapeHash` from the previous output: [source]
explain.executionStats.executionStages.inputStage [source]
In MongoDB 8.0 the pre-existing query shape was renamed the plan cache query shape and its queryHash field was renamed planCacheShapeHash; the new query shape is identified by queryShapeHash. The two hashes differ in form (queryShapeHash is a 64-char hex string, planCacheShapeHash an 8-char hex string in the docs example). [source]
If the operation is successful but the `hidden` value has not changed (specifically, hiding an already hidden index or unhiding an already unhidden index), the command omits the `hidden_old` and `hidden_new` fields from the output. [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]
- Num Yields (`numYields`): Frequent yields suggest resource contention or long-running operations that are pausing, potentially impacting overall throughput. [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]
If you specify an index that does not exist, the operation errors. [source]
Assume the following indexes exist on the `movies` collection: [source]
Time in milliseconds the query planner spent on query optimization. This result doesn't include time spent optimizing inner $lookup queries. [source]
- Performs a collection scan. [source]
Filtering on `indexDetails` using either `indexDetailsKey` or `indexDetailsName` will only return a single matching index. If no exact match is found, `indexDetails` will show information on all indexes for the collection. [source]
| Metric | Description | | --- | --- | | Execution Count | Number of queries executed per hour which match the query shape. | | Average Execution Time | Average execution time in milliseconds for queries which match the query shape. | | Average Query Targeting | Average number of documents read for every document returned by matching queries. A higher query targeting score indicates a greater degree of inefficiency. For more information on query targeting, see [Query Targeting.](https://www.mongodb.com/docs/atlas/performance-advisor.md#std-label-query-targeting) | | Average Docs Scanned | Aver [source]
The Performance Advisor also shows each executed sample query that matches the query shape, with specific metrics for that query. [source]
The Performance Advisor monitors queries that take longer than `100` milliseconds to execute and groups these queries into common [query shapes](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-shape). The Performance Advisor calculates the inefficiency of each query shape by considering the following aggregated metrics from queries which match the shape: [source]
The total number of indexes. [source]
A document that reports observability metrics for multikey path changes on both ordinary indexes and [wildcard indexes.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) [source]
The number of new multikey metadata paths recorded for ordinary indexes while recording the path during a multi-document transaction. [source]
The number of new multikey metadata paths recorded for ordinary indexes while recording the path outside a multi-document transaction. [source]
The number of new multikey metadata paths recorded for [wildcard indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) while recording the path during a multi-document transaction. [source]
The number of new multikey metadata paths recorded for [wildcard indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) while recording the path outside a multi-document transaction. [source]
The number of side transactions used to record multikey path changes for ordinary indexes. [source]
```javascript db.siteAnalytics.dropIndex( { "url_1" } ) ``` [source]
```javascript db.siteAnalytics.dropIndex( { "url_1_dummyField_1" } ) ``` [source]
An index is unused if it doesn't support any queries. [source]
The Performance Advisor flags an index as unused if it hasn't supported a query in 7 or more days after it was created or the server was restarted. [source]
- Keys Examined: The total number of index entries scanned by the database during query execution. [source]
- Existing indexes are inefficient or not optimal for this specific query. To learn more, see [Indexes.](https://www.mongodb.com/docs/manual/indexes.md#std-label-indexes) [source]
- Uses Index (`usedIndex`): This boolean confirms whether a MongoDB index was used. If set to `false` for a query that should be indexed, add an [index.](https://www.mongodb.com/docs/manual/indexes.md#std-label-indexes) [source]
$indexStats takes an empty document ({ $indexStats: {} }), must be the first stage of an aggregation pipeline, is not allowed in transactions, and with access control requires at least the clusterMonitor role. [source]
accesses reports usage only for the node where the query runs, and only user-driven access. TTL-index deletions and chunk split/migration operations do not increment ops. MongoDB documents say to run $indexStats on each node for comprehensive stats. [source]
Zero ops can be a false negative for unique indexes: a uniqueness check on insert does not increment the ops counter, so an unused-for-reads unique index still enforces a constraint and must not be dropped on stats alone. [source]
For any given query, the MongoDB query planner chooses and caches an efficient query plan given the available indexes. The planner can use either the classic multi-planner or the cost-based ranker (CBR) to select a plan. [source]
system.profile.authorization is not included in db.currentOp() output. [source]
Unhides an existing index from the query planner. Once unhidden, the indexes are immediately available for use. [source]
| Parameter | Type | Description | | --- | --- | --- | | `index` | string or document | Specifies the index to unhide from the query planner. You can specify the index either by the index name or by the index specification document. To find the index name or index specification document, you can use the [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getindexes.md#mongodb-method-db.collection.getIndexes) method. To unhide a [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text.md#std-label-index-type-text) index, specif [source]
Optional. Specify the index name, either as a string or a document. If specified, the query planner only considers plans using the hinted index. For more details, see Specify an Index. [source]
- The query planner selects the wildcard index for satisfying the query predicate. [source]
- A city planner uses 2dsphere indexes to find parks that exist within city limits. [source]
Specifies the index to hide from the query planner. You can specify the index either by the index name or by the index specification document. [source]
MongoDB offers the ability to hide or unhide indexes from the query planner. By hiding an index from the planner, you can evaluate the potential impact of dropping an index without actually dropping the index. [source]
During the `$match` stage, the server can use an index if `$match` is the first stage in the pipeline, after any optimizations from the [query planner.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) [source]
The following example [hides](https://www.mongodb.com/docs/manual/core/index-hidden.md#std-label-index-type-hidden) an existing index on the `orders` collection. Specifically, the operation hides the index with the specification `{ shippedDate: 1 }` from the query planner. [source]
Each pattern counter name lists the stages of the winning plan in order, starting with the access path stage. For example, ixscanFetchSort counts winning plans that use an index scan, fetch the matching documents, and then sort them. [source]
The following aggregation operation finds movies created in 1994 and includes the `comment` option to provide tracking information in the `logs`, the `db.system.profile` collection, and `db.currentOp`. [source]
You can [hide an index](https://www.mongodb.com/docs/manual/core/index-hidden/) from the query planner to evaluate the potential impact of dropping an index without actually dropping the index. [source]
[`db.currentOp()`](https://www.mongodb.com/docs/manual/reference/method/db.currentop.md#mongodb-method-db.currentOp) and the [database profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) report the same basic diagnostic information for all CRUD operations, including the following: [source]
In previous versions of MongoDB, `cursor.explain()` returned the `clauses` array that detailed the indexes. [source]
| Field | Description | | --- | --- | | `"$ownOps"` | Boolean. If set to `true`, returns information on the current user's operations only. On [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instances, users are always authorized to run `currentOp` with `"$ownOps": true` to view their own operations. See [access control.](https://www.mongodb.com/docs/manual/reference/command/currentop.md#std-label-currentOp-access-control) | | `"$all"` | Boolean. If set to `true`, returns information on all operations, including operations on idle connectio [source]
If the query plan changes to use a different index, the method may return a different document. If your use case requires that a particular record is chosen consistently, you must use the `options` document to specify a sort. For details on using `findOne()` with an `options` document, see the [example.](https://www.mongodb.com/docs/manual/reference/method/db.collection.findone.md#std-label-findOne-with-options) [source]
4. Check the plan summary. [source]
If the attempt is unsuccessful, MongoDB applies a set of rules to decide whether the multi-planner should continue or if CBR should evaluate the plans to determine the optimal solution. CBR evaluates each node in a plan based on a cost function and its cardinality estimations. MongoDB selects the plan with the lowest overall cost as the winning plan. Currently, MongoDB only invokes the CBR for a small amount of queries. [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]
Percona treats the gap between examined and returned counts as the signal: 325 docs examined for 6 returned, and 2517 examined for 493 returned, are called not optimal. A better compound index brings examined equal to returned. [source]
Atlas also offers 'Query Targeting: Scanned / Returned', which counts index keys examined relative to documents returned against a user-defined threshold. It is not enabled by default. [source]
Percona's rule for field order in a compound index is most selective field first; it gives no formal selectivity definition or numeric threshold. MongoDB's docs example instead shows equality-before-range ordering winning, so selectivity alone is not the ordering rule. [source]
Queries that include a sort by [`$natural`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-operator-metaOp.-natural) order do **not** use indexes to fulfill the query predicate with the following exception: If the query predicate is an equality condition on the `_id` field `{ _id: <value> }`, then the query with the sort by [`$natural`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-operator-metaOp.-natural) order can use the `_id` index. [source]
Specify the `$natural` operator to the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) method to prevent MongoDB from using *any* index: [source]
You can also monitor collection-level [query latency](https://www.mongodb.com/docs/manual/reference/operator/aggregation/collStats/#latencystats-document) with [Namespace Insights](https://www.mongodb.com/docs/atlas/namespace-insights.md#std-label-namespace-insights) and query performance with the [Query Profiler.](https://www.mongodb.com/docs/atlas/tutorial/query-profiler.md#std-label-query-profiler) [source]
On a time series collection, you can specify hints using either the index name or the index key pattern. To get the names of the indexes on a collection, use the [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getindexes.md#mongodb-method-db.collection.getIndexes) method. [source]
On a time series collection, you can specify hints using either the index name or the index key pattern. To get the names of the indexes on a collection, use `GetIndexes()`. [source]
- On a [time series collections](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-time-series-collection), you can only specify hints using the index name, not the index key pattern. [source]
Unless the [`find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find.md#mongodb-method-db.collection.find) query is an equality condition on the `_id` field `{ _id: <value> }`, you must explicitly specify the index with the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) method to run [`min()`.](https://www.mongodb.com/docs/manual/reference/method/cursor.min.md#mongodb-method-cursor.min) [source]
You can specify an index name or pattern using the hint option. [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 following operation explicitly hints to use the index `{ status: 1 }`: [source]
Atlas might not [log](https://www.mongodb.com/docs/atlas/mongodb-logs.md#std-label-mongodb-logs) the individual operations that contribute to the Query Targeting ratios due to automatically set thresholds. However, you can still use the Query Profiler and Query Targeting metrics to analyze and optimize query performance. [source]
The index that was used as a hint for the query [source]
The following aggregation operation includes the `hint` option to force the usage of the specified index: [source]
You can also monitor collection-level query latency with Namespace Insights and query performance with the Query Profiler. [source]
MongoDB supports the use of [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) with [`count()`](https://www.mongodb.com/docs/manual/reference/method/cursor.count.md#mongodb-method-cursor.count). See [Specify the Index to Use](https://www.mongodb.com/docs/manual/reference/method/cursor.count.md#std-label-count-method-hint) for an example. [source]
Atlas might not log the individual operations that contribute to the Query Targeting ratios due to automatically set thresholds. However, you can still use the Query Profiler and Query Targeting metrics to analyze and optimize query performance. [source]
Monitor Query Performance with the Query Profiler [source]
On time series collections a hint may be given only by index name, not key pattern. [source]
Maximum query planning time. [source]
A summary of the execution plan. [source]
Collation options on an existing index can be updated. To change other index options, drop the existing index with db.collection.dropIndex() then run createIndexes with the new options. [source]
If one of the indexes were dropped, or if a new index `{ year: 1, title: 1 }` were added, the `planCacheKey` for both query operations will change. [source]
The following example adds query settings for a [`find`](https://www.mongodb.com/docs/manual/reference/command/find.md#mongodb-dbcommand-dbcmd.find) command. The example provides fields in `setQuerySettings` for the `find` command, and includes the `orderDate_1` index in `allowedIndexes`. [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]
| Metric | Description | | --- | --- | | Total Execution Time | Total time in microseconds spent running queries with the given query shape. If the query resulted in [`getMore`](https://www.mongodb.com/docs/manual/reference/command/getMore.md#mongodb-dbcommand-dbcmd.getMore) commands, this metric includes the time spent processing the [`getMore`](https://www.mongodb.com/docs/manual/reference/command/getMore.md#mongodb-dbcommand-dbcmd.getMore) requests. This metric does not include time spent waiting for the client. | | Avg Execution Time | Average time in microseconds spent running queries wit [source]
[`$indexStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats) reports index usage metrics in the [accesses](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#std-label-indexStats-output-accesses) field only for the node where the query runs. For more comprehensive index usage statistics, run [`$indexStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats) on each node in the cluster. [source]
- To learn about query settings and indexes, see [`setQuerySettings`.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) [source]
Unhiding a hidden index resets its [`$indexStats`.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats) [source]
For each suggested index, the Performance Advisor shows the most commonly executed query shapes that the index would improve. For each query shape, the Performance Advisor displays the following metrics: [source]
The following query can use the index since the query predicate includes the condition `password: { $exists: true }` that matches documents matched by the index filter expression `password: { $exists: true }`: [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]
The type of query operation in the query shape affects the order of the fields used to construct the index. In general, the Performance Advisor ranks fields by their [cardinality.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-cardinality) [source]
Once the mongod completes the collection scan, it dumps the sorted keys into the index. [source]
The statistics reported by the [accesses](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#std-label-indexStats-output-accesses) field only apply to the node where the query is being run and only include index access driven by user requests. It does not include internal operations like deletion via [TTL indexes](https://www.mongodb.com/docs/manual/core/index-ttl.md#std-label-index-feature-ttl) or chunk split and migration operations. [source]
Hiding an unhidden index resets its $indexStats. [source]
If an index specified to [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) is still building, [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) attempts to stop the in-progress build. Stopping an index build has the same effect as dropping the built index. [source]
The `dropIndex` command returns the number of indexes in the collection prior to the command being run, and indicates whether the command was successful: [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 [`dropIndexes`](https://www.mongodb.com/docs/manual/reference/command/dropindexes.md#mongodb-dbcommand-dbcmd.dropIndexes) command drops one or more indexes (except the index on the `_id` field and the last remaining shard key index, if one exists) from the specified collection. [source]
Starting in MongoDB 8.3, if an array of index names includes a non-existent index, [`dropIndexes`](https://www.mongodb.com/docs/manual/reference/command/dropindexes.md#mongodb-dbcommand-dbcmd.dropIndexes) ignores the non-existent index and drops the remaining specified indexes. [source]
```javascript db.runCommand( { dropIndexes: "collection", index: "*" } ) ``` [source]
```javascript db.runCommand( { dropIndexes: "collection", index: "age_1" }) ``` [source]
```javascript db.runCommand( { dropIndexes: "collection", index: [ "age_1", "age_1_status_1" ] } ) ``` [source]
| Method | Description | | --- | --- | | [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) | Drops a specific index from the collection. | | [`db.collection.dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindexes.md#mongodb-method-db.collection.dropIndexes) | Drops all removable indexes from the collection or an array of indexes, if specified. | [source]
A document that reports statistics on all indexes on databases and collections in non-system namespaces only. `indexStats` does not report statistics on indexes in the `admin`, `local`, and `config` databases. [source]
A document that provides counters for each index type and the number of accesses on each index. Each index type under `indexStats.features` has a `count` field that counts the total number of indexes for that type, and an `accesses` field that counts the number of accesses on that index. [source]
Total number of in-bounds and out-of-bounds index keys examined by queries with the given query shape. [source]
Ratio of in-bounds and out-of-bounds index keys examined to indexes containing documents returned by queries with the given query shape. [source]
Total number of index keys inserted by queries with the given query shape. Available only for write commands on clusters running MongoDB 9.0 or later. [source]
Total number of index keys deleted by queries with the given query shape. Available only for write commands on clusters running MongoDB 9.0 or later. [source]
The type of query operation in the query shape affects the order of the fields used to construct the index. In general, the Performance Advisor ranks fields by their cardinality. [source]
This query scanned 10,000 documents and returned only 4 for a ratio of 2500, which is highly inefficient. No index keys were examined, so MongoDB scanned all documents in the collection, known as a [collection scan.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-collection-scan) [source]
Collection scans, counted separately based on whether the scan uses the clustered index. [source]
The following example clears all index filters on the `orders` collection: [source]
The following example clears the index filter containing the query on `Movie` and the collation `en_US` for the `orders` collection: [source]
The Data Explorer only shows Usage metrics for the primary node in your cluster. If your application primarily reads from secondary nodes, the Usage metrics do not fully reflect index usage across your cluster. [source]
The Performance Advisor inspects only the 20 most active collections for unused indexes. [source]
Document listing the index filters. See [Output.](https://www.mongodb.com/docs/manual/reference/command/plancachelistfilters.md#std-label-planCacheListFilters-output) [source]
The query predicate associated with this filter. Although the [`query`](https://www.mongodb.com/docs/manual/reference/command/plancachelistfilters.md#mongodb-data-planCacheListFilters.filters.query) shows the specific values used to create the index filter, the values in the predicate are insignificant; i.e. query predicates cover similar queries that differ only in the values. [source]
For case sensitive regular expression queries, if an index exists for the field, then MongoDB matches the regular expression for the values in the index. This can be faster than a collection scan. [source]
Indicates the query performed a full collection scan. To correct this, [Create an Index.](https://www.mongodb.com/docs/manual/core/indexes/create-index.md#std-label-manual-create-an-index) [source]
- Hidden indexes are updated upon write operations to the collection and continue to consume disk space and memory. As such, they are included in various statistics operations, such as [`db.collection.stats()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.stats.md#mongodb-method-db.collection.stats) and [`$indexStats`.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats) [source]
- Hiding an unhidden index or unhiding a hidden index resets its [`$indexStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats). Hiding an already hidden index or unhiding an already unhidden index does not reset the [`$indexStats`.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats) [source]
Hidden indexes are updated upon write operations to the collection and continue to consume disk space and memory. As such, they are included in various statistics operations, such as db.collection.stats() and $indexStats. [source]
As an alternative, you can [`drop`](https://www.mongodb.com/docs/manual/reference/command/dropindexes.md#mongodb-dbcommand-dbcmd.dropIndexes) any misconfigured TTL indexes and recreate them later using the [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.createIndexes) command. [source]
Index statistics reset on mongod restart, on index drop and recreation, and on any collMod modification of the index. Hiding an unhidden index also resets its $indexStats, so a hide-then-measure window starts at the hide time. [source]
On sharded clusters $indexStats is local to each shard primary and a mongos does not aggregate it; an index can show zero on one shard and serve queries on another, so sum accesses.ops across all shards before calling an index unused (Netdata's guide; MongoDB docs state the per-node scope). [source]
Any DDL event clears the plan cache for the relevant collection (drop collection; create, delete or hide an index). The cache is in memory only and is lost on mongod restart or shutdown. LRU eviction removes the least recently used entry regardless of state. Manual clearing uses getPlanCache().clear() or clearPlansByQuery(). [source]
Total query planning time. [source]
Minimum query planning time. [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]
- A link to the report subscription settings in Project Settings. To learn more, see [Manage Project Settings.](https://www.mongodb.com/docs/atlas/tutorial/manage-project-settings.md#std-label-project-settings) [source]
The following example sets for a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instance: [source]
The maximum number of milliseconds to wait for a lock acquisition before performing writes to [`profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collections. [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]
You can specify the amount of time to wait before abandoning writes to [`profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collections by setting the [`internalQueryGlobalProfilingLockDeadlineMs`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.internalQueryGlobalProfilingLockDeadlineMs) parameter. [source]
- Parameter names such as the `partitionBy` parameter in [`$setWindowFields`.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/setwindowfields.md#mongodb-pipeline-pipe.-setWindowFields) [source]
| Field | Type | Literal or Normalized | | --- | --- | --- | | `key.queryShape.collation` | Document | Normalized | | `key.queryShape.key` | String | Literal | | `key.queryShape.query` | Document | Normalized | [source]
| Field | Type | Literal or Normalized | | --- | --- | --- | | `key.queryShape.q` | Document | Normalized | | `key.queryShape.u` | Document or Array | Normalized | | `key.queryShape.c` | Document | Normalized | | `key.queryShape.arrayFilters` | Array of documents | Normalized | | `key.queryShape.multi` | Boolean | Literal | | `key.queryShape.upsert` | Boolean | Literal | | `key.queryShape.let` | Document | Normalized | | `key.queryShape.collation` | Document | Literal | [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]
$queryStats normalises literal values to types (e.g. {item:'card'} becomes {item:'?string'}) but keeps readConcern/readPreference literal. With transformIdentifiers (algorithm hmac-sha-256, hmacKey) it HMACs field, collection and database names but not operators or parameter names. [source]
Per-entry metrics include execCount, totalExecMicros, firstResponseExecMicros, docsReturned (sum/max/min/sumOfSquares), and cpuNanos (Linux only, new in 8.2); sumOfSquares exposes variance. Aggregate stage counters are available in the newer output. [source]
In sharded clusters (new in 8.3) mongod and mongos each record query stats and shards also record stats for queries originating at mongos. Change-stream stats update on cursor creation, getMore and close. [source]
explain.queryPlanner information details the plan selected by the query optimizer. [source]
Sum of squares of query planning times. [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]
- To see how often your indexes are used, see [Measure Index Use.](https://www.mongodb.com/docs/manual/tutorial/measure-index-use.md#std-label-index-measure-index-use) [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]
A boolean that indicates whether the query planner evaluated multiple plans before choosing the winning execution plan for the query. [source]
A boolean that indicates whether the query system evicted a cached plan and re-evaluated all candidate plans. [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]
For more information on optimizing queries, see explain and Query Plans. [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]
Documents Returned displays 3809 to indicate that the winning query plan returns 3,809 documents. [source]
A document that holds metrics on the cost-based ranking (CBR) of query plans. [source]
Number of times the cost-based ranker chose a winning plan. [source]
A histogram measuring the amount of time in microseconds spent on cost-based ranking query plans, which includes both sampling and ranking time. [source]
A histogram measuring the amount of time in microseconds the server spent on sampling during cost-based ranking of query plans. [source]
Amount of time in microseconds spent on cost-based ranking query plans, which includes both sampling and ranking time. [source]
Number of candidate plans compared by the cost-based ranker. [source]
Number of candidate plans for which the cost-based ranker could not estimate a cost. [source]
Number of candidate plans that tied in cost-based ranking. [source]
Amount of time in microseconds the server spent on sampling during cost-based ranking of query plans. [source]
Provides information on the query plan for the [`db.collection.find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find.md#mongodb-method-db.collection.find) method. [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]
Counts of the overall shapes of the winning plans. Each winning plan matches at most one pattern. [source]
The metrics.queryPlanner.planShapeCounters document records how often MongoDB selected each plan shape for queries with the given key. Use these counters to learn which query plans your workload relies on most. [source]
Counts the overall shape of each winning plan. The patterns are mutually exclusive, so each query execution increments at most one pattern counter. [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]
The selectivity of regular expressions depends on the expressions themselves. For details, see regular expression and index use. [source]
**Note: The explain output is subject to change between releases.** [source]
The selectivity of [`regular expressions`](https://www.mongodb.com/docs/manual/reference/operator/query/regex.md#mongodb-query-op.-regex) depends on the expressions themselves. For details, see [regular expression and index use.](https://www.mongodb.com/docs/manual/reference/operator/query/regex.md#std-label-regex-index-use) [source]
A boolean that indicates whether the query system evicted a [cached plan](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) and re-evaluated all candidate plans. [source]
A string that indicates the specific reason a [cached plan](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) was evicted. [source]
The time, in microseconds, that the `find` or `aggregate` command spent in [query planning.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) [source]
The following example clears all the cached query plans for the `orders` collection: [source]
For more information on optimizing queries, see [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain.md#mongodb-dbcommand-dbcmd.explain) and [Query Plans.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) [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]
For more information, see Query Plan Options. [source]
explain.queryPlanner.winningPlan [source]
explain.queryPlanner.winningPlan.stage [source]
explain.queryPlanner.winningPlan.type [source]
explain.queryPlanner.winningPlan.isCached [source]
explain.queryPlanner.winningPlan.costEstimate [source]
explain.queryPlanner.winningPlan.cardinalityEstimate [source]
explain.queryPlanner.winningPlan.numKeysEstimate [source]
explain.queryPlanner.winningPlan.numDocsEstimate [source]
explain.queryPlanner.winningPlan.estimatesMetadata [source]
explain.queryPlanner.winningPlan.estimatesMetadata.ceSource [source]
explain.queryPlanner.winningPlan.queryPlan [source]
explain.queryPlanner.winningPlan.queryPlan.stage [source]
explain.queryPlanner.winningPlan.queryPlan.type [source]
explain.queryPlanner.winningPlan.queryPlan.planNodeId [source]
Unique integer field that identifies each stage in the execution plan. Field is included in all stages throughout the explain results. [source]
explain.queryPlanner.winningPlan.slotBasedPlan [source]
explain.queryPlanner.winningPlan.slotBasedPlan.stages [source]
explain.queryPlanner.rejectedPlans [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]
The returned document may vary depending on the number of documents that match the query criteria, and the [query plan](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) used: [source]
The [`$natural`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-operator-metaOp.-natural) parameter returns items according to their [natural order](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-natural-order) within the database. This ordering is an internal implementation feature, and you should not rely on any particular ordering of the documents. [source]
The [`cursor.hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint.md#mongodb-method-cursor.hint) method has the following parameter: [source]
```javascript db.products.find().min( { item: 'apple', type: 'jonagold' } ).hint( { item: 1, type: 1 } ) ``` [source]
```javascript db.products.find().min( { price: Decimal128("1.39") } ).max( { price: Decimal128("1.99") } ).hint( { price: 1 } ) ``` [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]
Database profiler output, in the command.comment field. [source]
Returns the details for a single query shape. [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]
The `planCacheShapeHash` and `planCacheKey` are available in: [source]
- `PlanCache.listQueryShapes()` method/`planCacheListQueryShapes` command [source]
- `PlanCache.getPlansByQuery()` method/`planCacheListPlans` command [source]
`setQuerySettings` defines query settings used by the [`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), and [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate) commands. [source]
You can add or update query settings using either of the two syntax specifications shown in this section. [source]
- A `$db` field to specify the database for the query settings. [source]
The `settings` document in the `setQuerySettings` command takes the following fields: [source]
2. Add query settings for a find command [source]
3. (Optional) Verify the query settings [source]
5. (Optional) Obtain the query settings [source]
The following example uses a [`$querySettings`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querysettings.md#mongodb-pipeline-pipe.-querySettings) stage in an aggregation pipeline to obtain the query settings: [source]
```javascript db.aggregate( [ { $querySettings: {} } ] ) ``` [source]
Truncated output, which includes the `queryShapeHash` field: [source]
6. Add query settings for a distinct command [source]
The following example adds query settings for a [`distinct`](https://www.mongodb.com/docs/manual/reference/command/distinct.md#mongodb-dbcommand-dbcmd.distinct) command: [source]
7. Add query settings for an aggregate command [source]
The following example adds query settings for an [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate) command: [source]
Updates the rejection status of a query shape. [source]
Docs Home / Development / CRUD Operations / Read / Database Profiler [source]
The database profiler captures data information about read and write operations, cursor operations, and database commands. To configure the database profile and set the thresholds for capturing profile data, see the Database Profiler section. [source]
The database profiler writes data in the system.profile collection, which is a capped collection. To view the profiler's output, use normal MongoDB queries on the system.profile collection. [source]
It is no longer possible to perform any operation, including reads, on the system.profile collection from within a transaction. [source]
For any single operation, the documents created by the database profiler includes a subset of the following fields. The precise selection of fields in these documents depends on the type of operation. [source]
system.profile.originatingCommand [source]
system.profile.inUseTrackedMemBytes [source]
system.profile.peakTrackedMemBytes [source]
system.profile.hasSortStage [source]
Only appears if usedDisk is true. [source]
system.profile.fromMultiPlanner [source]
system.profile.replanReason [source]
system.profile.keysInserted [source]
system.profile.writeConflicts [source]
For more information about planCacheShapeHash and planCacheKey, see planCacheShapeHash and planCacheKey. [source]
system.profile.queryFramework [source]
The system.profile.locks provides information for various lock types and lock modes held during the operation. [source]
system.profile.locks.acquireCount [source]
system.profile.locks.acquireWaitCount [source]
system.profile.locks.timeAcquiringMicros [source]
system.profile.locks.deadlockCount [source]
system.profile.authorization [source]
system.profile.authorization.startedUserCacheAcquisitionAttempts [source]
system.profile.authorization.completedUserCacheAcquisitionAttempts [source]
system.profile.authorization.userCacheWaitTimeMicros [source]
The system.profile.storage information provides metrics on the storage engine data and wait time for the operation. [source]
system.profile.storage.data.bytesRead [source]
system.profile.storage.data.timeReadingMicros [source]
system.profile.storage.data.bytesWritten [source]
system.profile.storage.data.timeWritingMicros [source]
system.profile.storage.timeWaitingMicros.cache [source]
system.profile.storage.timeWaitingMicros.schemaLock [source]
system.profile.storage.timeWaitingMicros.handleLock [source]
system.profile.responseLength [source]
Before MongoDB 7.0.22, 8.0.5, and 8.1.0, planningTimeMicros might include non-planning work, such as a sharding metadata refresh. planningTimeMicros might also include cached-plan trial-run time, even if the query doesn't replan. [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]
The system.profile.execStats presents the statistics as a tree; each node provides the statistics for the operation executed during that stage of the query operation. [source]
system.profile.execStats.stage [source]
Example system.profile Document [source]
"planCacheShapeHash" : "811451DD", [source]
"planCacheKey" : "759981BA", [source]
"executionTimeMillisEstimate" : 0, [source]
The system.profile collection includes metrics for the getMore operation. In this example, getMore returns additional documents from the test.report collection. [source]
"executionTimeMillisEstimate" : 103771, [source]
Atlas supports Query Shape Insights on only dedicated clusters (M10 and above) running MongoDB version 8.0 and above. [source]
After you upgrade a cluster from MongoDB 8.x to 9.0, metric totals in Query Shape Insights may appear significantly different than before the upgrade. This difference reflects the change in sampling method, not a change in your cluster's workload. [source]
2. Go to Query Shape Insights. [source]
The Query Shapes tab displays by default. [source]
Atlas can chart each metric for up to five query shapes at a time. By default, Atlas charts each metric for the five query shapes with the highest Total Execution Time. You can choose to chart different query shapes by selecting or deselecting the checkbox in the row of your desired query shapes. You can manage which query shapes to chart from the table, by selecting or deselecting the checkbox in the row of your desired query shapes. [source]
[`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) users can also manually subscribe to or unsubscribe from Query Shape Reports regardless of whether the project has received a query targeting alert. To learn more, see [Manage Report Subscriptions.](https://www.mongodb.com/docs/atlas/query-shape-insights.md#std-label-query-shape-reports-manage) [source]
If no qualifying query shapes exist for a given reporting period, Atlas skips that report and resumes with the next scheduled report. [source]
- A link to the Query Shape Insights page for the cluster. [source]
- A table of up to five query shapes, ranked by total execution time. Each query shape must have at least 10 executions in the reporting period to appear. [source]
- A link to each query shape's details on the Query Shape Insights page. [source]
| Column | Description | | --- | --- | | Collection Name | Name of the collection that the query shape targets. | | Average Execution Time | Average time spent running queries with the given query shape. | | Execution Count | Total number of times that queries with the given query shape ran. | | Docs Examined:Returned Ratio | Ratio of documents examined to documents returned by queries with the given query shape. | [source]
You can subscribe to or unsubscribe from Query Shape Reports in your project's settings. This setting controls reports for all users in the project. Only users with the [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) role can change the subscription, and only [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) users receive the reports. [source]
1. Toggle the Query Shape Reports setting. [source]
By default, Query Shape Insights displays metric charts for the top five query shapes with the highest Total Execution Time. You can select up to five query shapes to chart in the Query Shape Insights table. [source]
- **Query Shape**: In the Search by Query Shape search box, input the query shape or its associated query hash. [source]
You can sort the Query Shape Insights table by one or more metric columns to help identify which query shapes to chart. [source]
Click the checkbox in the row of your desired query shape. [source]
You can select up to five query shapes at a time. [source]
| Field Name | Description | | --- | --- | | `total` | The total number of queries that performed a collection scan. | | `nonTailable` | The number of queries that performed a collection scan, but didn't use a [tailable cursor.](https://www.mongodb.com/docs/manual/core/tailable-cursors.md#std-label-tailable-cursors-landing-page) | [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]
On [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod), if the [database profiler level](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-level) is `2`, full logging is enabled on the profiler and the [`diagnostic log`.](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--logpath) [source]
At [database profiler level](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-level) `1`, the following settings modify both the profiler and the [`diagnostic log`:](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--logpath) [source]
If the [database profiler level](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-level) is `0`, the [database profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) is disabled. At level `0` the following settings only modify the diagnostic log: [source]
- `0` to set the `slowms`, `sampleRate`, and `filter` for the diagnostic log; [source]
The profiler is off by default. [source]
Profiling can degrade performance and expose unencrypted query data in the system log. Carefully consider any performance and security implications before configuring and enabling the profiler on a production deployment. [source]
See [Profiler Overhead](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiling-overhead) for more information on potential performance degradation. [source]
Atlas Core clusters support all [database profiler levels.](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-level) [source]
The [`profile`](https://www.mongodb.com/docs/manual/reference/command/profile.md#mongodb-dbcommand-dbcmd.profile) command obtains a write lock on the affected database while enabling or disabling the profiler. This is typically a short operation. The lock blocks other operations until the [`profile`](https://www.mongodb.com/docs/manual/reference/command/profile.md#mongodb-dbcommand-dbcmd.profile) command has completed. [source]
[`db.setProfilingLevel()`](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#mongodb-method-db.setProfilingLevel) provides a wrapper around the [`profile`](https://www.mongodb.com/docs/manual/reference/command/profile.md#mongodb-dbcommand-dbcmd.profile) command. [source]
The [`db.setProfilingLevel()`](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#mongodb-method-db.setProfilingLevel) method has the following form: [source]
The `filter` and `note` fields only appear in the output if they were present in the previous [level](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-level) setting. [source]
You can set a `filter` without enabling the database profiler. The following example uses a filter with a [profiling level](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-level) of `0`. [source]
Starting in MongoDB 9.0, you can also configure this parameter with query settings. To set query settings, use [`setQuerySettings`.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) [source]
- the [`drop`](https://www.mongodb.com/docs/manual/reference/command/drop.md#mongodb-dbcommand-dbcmd.drop) command, the [`dropIndexes`](https://www.mongodb.com/docs/manual/reference/command/dropindexes.md#mongodb-dbcommand-dbcmd.dropIndexes) command, the [`validate`](https://www.mongodb.com/docs/manual/reference/command/validate.md#mongodb-dbcommand-dbcmd.validate) command; and [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]
The fraction of read operations that MongoDB samples for [`$queryStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#mongodb-pipeline-pipe.-queryStats). The value must be between `0.0` and `1.0`. To sample all read operations, set the value to `1.0`. To stop sampling read operations, set the value to `0`. [source]
The fraction of write operations that MongoDB samples for [`$queryStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#mongodb-pipeline-pipe.-queryStats). The value must be between `0.0` and `1.0`. To sample all write operations, set the value to `1.0`. To stop sampling write operations, set the value to `0`. [source]
You can add query settings for [`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), and [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate) commands. [source]
query planning in plan cache scenarios. [source]
Starting in MongoDB 8.0, the new query shape supports: [source]
$queryStats query shape statistics. [source]
operation rejection filters to block find, aggregation, and distinct commands that have a specified query shape. [source]
queryShapeHash: 'AB8ECADEE8F0EB0F447A30744EB4813AE7E0BFEF523B0870CA10FCBC87F5D8F1' [source]
planCacheShapeHash: '48E51110' [source]
In the example in the previous section, the example sorts by the totalNumber field. If you change the query sort from totalNumber to a different field, the query has a different query shape. [source]
queryShapeHash: 'AC1ECADBE8F1EB0F417A30741AB4813BE7E0BFEF523B0870CA11FCBC87F1A8B2' [source]
planCacheShapeHash: '31A52130' [source]
MongoDB derives the queryShapeHash from the query shape itself, not from the deployment that runs the query. In current supported versions, the same query shape is expected to produce the same queryShapeHash: [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]
querySettings: <document> // Added in MongoDB 9.0, [source]
You can add query settings for find, distinct, and aggregate commands. [source]
Returns the metadata and statistics summary for a given query shape hash. [source]
The [`$indexStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats) stage takes an empty document and has the following syntax: [source]
- `$indexStats` must be the first stage in an aggregation pipeline. [source]
Returns a list of query shape statistics summaries for a given cluster. [source]
Query shape statistics provide performance insights about MongoDB queries, helping users identify problematic query patterns and potential optimizations. [source]
The [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) method takes the following parameter: [source]
[`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) obtains an exclusive lock on the specified collection for the duration of the operation. All subsequent operations on the collection must wait until [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) releases the lock. [source]
).explain("executionStats") [source]
totalDocsExamined: 21349, [source]
executionStats.totalDocsExamined display 3809 to indicate that MongoDB scanned 3,809 documents. [source]
In [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#std-program-mongosh), this command can also be run through the [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) and [`db.collection.dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindexes.md#mongodb-method-db.collection.dropIndexes) helper methods.. [source]
[`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) provides the helper methods [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindex.md#mongodb-method-db.collection.dropIndex) and [`db.collection.dropIndexes()`:](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropindexes.md#mongodb-method-db.collection.dropIndexes) [source]
```javascript db.collection.dropIndex("age_1"); ``` [source]
The total number of [`profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collections on all databases. [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]
A document that reports on the number of queries that performed a collection scan. [source]
The number of queries that performed a collection scan that did not use a [tailable cursor.](https://www.mongodb.com/docs/manual/core/tailable-cursors.md#std-label-tailable-cursors-landing-page) [source]
The number of queries that performed a collection scan on a [`profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection that did not use a [tailable cursor.](https://www.mongodb.com/docs/manual/core/tailable-cursors.md#std-label-tailable-cursors-landing-page) [source]
The number of queries that performed a collection scan on a [`profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection that used a [tailable cursor.](https://www.mongodb.com/docs/manual/core/tailable-cursors.md#std-label-tailable-cursors-landing-page) [source]
The total number of queries that performed a collection scan on a [`profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection. This includes queries that used both tailable and non-tailable cursors. [source]
- The sync source's majority commit point has advanced since the last batch sent to this secondary. [source]
Total size of the plan cache in bytes. [source]
Prior to version 7.2, information on the plan cache size was stored in the `query.planCacheTotalSizeEstimateBytes` field. [source]
Total number of databases where the [Database Profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) is disabled after reaching the lock timeout threshold. [source]
You can specify the maximum number of lock timeouts per second that disable the profiler by setting the [`internalProfilingMaxAbandonedWritesPerSecondPerDb`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.internalProfilingMaxAbandonedWritesPerSecondPerDb) parameter. [source]
Number of queries that the `$queryStats` virtual collection has evicted due to space contraints. [source]
Current estimated size of objects in the `$queryStats` virtual collection. [source]
Document with configuration counts and usage for query settings. [source]
Total number of query settings. [source]
Total number of query settings that have the `reject` field set to `true`. To set the `reject` field, use `setQuerySettings`. [source]
Total size in bytes for query settings. [source]
Forbids operations that require a collection scan. See [`notablescan`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.notablescan) for additional information. [source]
Configures the [database profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md) level. The following profiler levels are available: [source]
The profiler is off and does not collect any data. This is the default profiler level. [source]
The profiler collects data for operations that exceed the `slowms` threshold or match a specified [filter.](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-options-filter) [source]
- The profiler only captures operations that match the [filter.](https://www.mongodb.com/docs/manual/reference/method/db.setprofilinglevel.md#std-label-set-profiling-level-options-filter) [source]
The profiler collects data for all operations. [source]
For `mongod` instances, [`--slowms`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--slowms) affects the diagnostic log and, if enabled, the profiler. [source]
For `mongod` instances, [`--slowOpSampleRate`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--slowOpSampleRate) affects the diagnostic log and, if enabled, the profiler. [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]
- Do not depend on the profiling level. [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]
Monitor Query Shape Statistics with Query Shape Insights [source]
How Atlas Collects Query Shape Statistics [source]
Total time in microseconds spent running queries with the given query shape. If the query resulted in getMore commands, this metric includes the time spent processing the getMore requests. This metric does not include time spent waiting for the client. [source]
Average time in microseconds spent running queries with the given query shape. If the query resulted in getMore commands, this metric includes the time spent processing the getMore requests. This metric does not include time spent waiting for the client. [source]
Total number of times that queries with the given query shape have been executed. [source]
Total number of documents examined by queries with the given query shape. [source]
Total number of documents returned by queries with the given query shape. [source]
Ratio of documents examined to documents returned by queries with the given query shape. [source]
Total number of documents matched by queries with the given query shape. Available only for write commands on clusters running MongoDB 9.0 or later. [source]
Total number of documents modified by queries with the given query shape. Available only for write commands on clusters running MongoDB 9.0 or later. [source]
Total number of documents upserted by queries with the given query shape. Available only for write commands on clusters running MongoDB 9.0 or later. [source]
Total number of documents inserted by queries with the given query shape. Available only for write commands on clusters running MongoDB 9.0 or later. [source]
Total number of documents deleted by queries with the given query shape. Available only for write commands on clusters running MongoDB 9.0 or later. [source]
Execution runtime in microseconds for the most recent query with the given query shape. [source]
Project Owner users can also manually subscribe to or unsubscribe from Query Shape Reports regardless of whether the project has received a query targeting alert. To learn more, see Manage Report Subscriptions. [source]
Name of the collection that the query shape targets. [source]
Average time spent running queries with the given query shape. [source]
Total number of times that queries with the given query shape ran. [source]
- [Query Shape Reports](https://www.mongodb.com/docs/atlas/query-shape-insights.md#std-label-query-shape-reports), which send a summary of inefficient query shapes to Project Owners by email. [source]
- The [Query Profiler](https://www.mongodb.com/docs/atlas/tutorial/query-profiler.md#std-label-query-profiler), which describes specific inefficient queries executed on the cluster. [source]
2. Go to the Query Profiler tab. [source]
Click the Query Profiler tab. [source]
$queryStats collects and reports metrics for aggregate(), find(), distinct(), count(), update(), insert(), deleteOne(), and deleteMany() queries. $queryStats does not collect information for queries that use Queryable Encryption. [source]
The $queryStats stage is enabled on deployments hosted on MongoDB Atlas with a cluster tier of at least M10. [source]
$queryStats must be the first stage in the pipeline. [source]
Specifies additional transformation options for the $queryStats output. [source]
The following sections describe behavioral details of the $queryStats stage. [source]
How $queryStats Groups Returned Documents [source]
$queryStats preserves literal values for options like readConcern and readPreference. [source]
For the complete list of options included in a query stats entry, see find Command Query Shape. [source]
How $queryStats Transforms Data Using transformIdentifiers [source]
MongoDB records $queryStats operations in the deployment logs. By default, MongoDB only logs the invocation of $queryStats operations, not the operation's output. For $queryStats operations that include the transformIdentifiers option, you can specify whether the transformed output is included in the log entry. [source]
Each unique combination of attributes creates a separate entry in the $queryStats virtual collection. [source]
A hashed representation of the values in the key. Each unique keyHash value corresponds to a unique entry in the $queryStats memory store. [source]
Collection scan stages, counted separately based on whether the stage applies a filter. [source]
Fetch stages, counted separately based on whether the stage applies a filter. [source]
The fields in key.queryShape vary based on the command that resulted in the query stats entry. $queryStats creates query stats entries for aggregate, find, distinct, count, update, insert, and delete commands. [source]
Each query shape property corresponds to a query option. For example, key.queryShape.sort corresponds to the sort() specification for the query shape. [source]
The following table describes the query shape properties for find commands. [source]
key.queryShape.projection [source]
key.queryShape.singleBatch [source]
key.queryShape.showRecordId [source]
key.queryShape.oplogReplay [source]
key.queryShape.allowDiskUse [source]
The following table describes the query shape properties for aggregate commands. [source]
key.queryShape.allowPartialResults [source]
The following table describes the query shape properties for distinct commands. [source]
The following table describes the query shape properties for count commands. [source]
The following table describes the query shape properties for update commands. $queryStats tracks query shape statistics for each update statement in the updates array, not for the top-level update command as a whole. [source]
key.queryShape.arrayFilters [source]
$queryStats does not collect query shape statistics for update operations on time series collections. [source]
The following table describes the query shape properties for insert commands. $queryStats tracks query shape statistics once for the entire insert command, not for each document in the documents array. MongoDB always normalizes documents to a fixed placeholder value, regardless of the number or contents of the inserted documents. [source]
$queryStats does not collect query shape statistics for insert operations on time series collections. [source]
The following table describes the query shape properties for delete commands. $queryStats tracks query shape statistics for each delete statement in the deletes array, not for the top-level delete command as a whole. [source]
$queryStats does not collect query shape statistics for delete operations on time series collections. [source]
The example $queryStats output in the following sections may vary based on the execution of other commands. [source]
usedDisk: {true: Long("0"), false: Long("1")}, [source]
const pipeline = [{ $queryStats: {} }]; [source]
MongoDB Atlas periodically uses $queryStats to collect anonymized data about your queries, which helps improve MongoDB products. Your data may also be used to make feature suggestions based on usage. MongoDB retains the data it collects with $queryStats for four years. [source]
On a system with profiling enabled, you can then query the `system.profile` collection to see all recent similar aggregations, as shown below: [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]
| Field | Necessity | Type | Description | | --- | --- | --- | --- | | `transformIdentifiers` | Optional | Document | Specifies additional transformation options for the `$queryStats` output. | | `transformIdentifiers``.algorithm` | Required if specifying the `transformIdentifiers` object | String | The type of hash transformation applied to namespace information and field names in output. The only currently supported `algorithm` value is `hmac-sha-256`. | | `transformIdentifiers``.hmacKey` | Required if specifying the `transformIdentifiers` object | binData | The private key input in the HMAC [source]
- To run `$queryStats` without the `transformIdentifiers` option, the user must have the [`queryStatsRead`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-queryStatsRead) privilege action. [source]
- To run `$queryStats` with the `transformIdentifiers` option, the user must have the both the [`queryStatsRead`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-queryStatsRead) and [`queryStatsReadTransformed`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-queryStatsReadTransformed) privilege actions. [source]
For the complete list of options included in a query stats entry, see [find Command Query Shape.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#std-label-queryStats-find-query-shape) [source]
`$queryStats` does not collect query shape statistics for `update` operations on [time series collections.](https://www.mongodb.com/docs/manual/core/timeseries-collections.md#std-label-manual-timeseries-collection) [source]
`$queryStats` does not collect query shape statistics for `insert` operations on [time series collections.](https://www.mongodb.com/docs/manual/core/timeseries-collections.md#std-label-manual-timeseries-collection) [source]
`$queryStats` does not collect query shape statistics for `delete` operations on [time series collections.](https://www.mongodb.com/docs/manual/core/timeseries-collections.md#std-label-manual-timeseries-collection) [source]
The `$planCacheStats` stage must be the first stage in the pipeline. The stage has the following syntax: [source]
`$planCacheStats` must be the first stage in an aggregation pipeline. [source]
- `$planCacheStats` requires read concern level [`"local"`.](https://www.mongodb.com/docs/manual/reference/read-concern-local.md#mongodb-readconcern-readconcern.-local-) [source]
The output of `$planCacheStats` depends on the query engine used to complete the query. The value of the `version` field of the `$planCacheStats` indicates which query engine was used: [source]
For queries that use the classic execution engine, `$planCacheStats` returns a document similar to the following: [source]
The following aggregation pipeline uses `$planCacheStats` to return information about the plan cache entries for the collection: [source]
Returns query settings previously added with [`setQuerySettings`](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings). The settings apply to the entire cluster. The cluster retains the settings after shutdown. [source]
If you use multiple pipeline stages, put `$querySettings` first in the pipeline. [source]
`$querySettings` takes this field: [source]
2. Add the query settings [source]
The following `setQuerySettings` example adds query settings: [source]
3. Return the query settings [source]
The database profiler captures data information about read and write operations, cursor operations, and database commands. To configure the database profile and set the thresholds for capturing profile data, see the [Database Profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) section. [source]
It is no longer possible to perform any operation, including reads, on the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection from within a [transaction.](https://www.mongodb.com/docs/manual/core/transactions.md#std-label-transactions) [source]
The [`system.profile.locks`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks) provides information for various [lock types and lock modes](https://www.mongodb.com/docs/manual/faq/concurrency.md#std-label-faq-concurrency-locking) held during the operation. [source]
[`timeAcquiringMicros`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.timeAcquiringMicros) divided by [`acquireWaitCount`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.acquireWaitCount) gives an approximate average wait time for the particular lock mode. [source]
The [`system.profile.storage`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.storage) information provides metrics on the storage engine data and wait time for the operation. [source]
The [`system.profile.execStats`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.execStats) presents the statistics as a tree; each node provides the statistics for the operation executed during that stage of the query operation. [source]
The following fields list for [`execStats`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.execStats) is not meant to be exhaustive as the returned fields vary per stage. [source]
The following examples present sample documents found in the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection for operations on a standalone: [source]
The following document in the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection shows metrics for a sample query operation on the `test.report` collection: [source]
- [atlas api queryShapeInsights getClusterQueryShape](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-api-queryshapeinsights-getclusterqueryshape.md#std-label-atlas-api-queryShapeInsights-getClusterQueryShape) - Returns the details for a single query shape. [source]
- [atlas api queryShapeInsights getQueryShapeDetails](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-api-queryshapeinsights-getqueryshapedetails.md#std-label-atlas-api-queryShapeInsights-getQueryShapeDetails) - Returns the metadata and statistics summary for a given query shape hash. [source]
- [atlas api queryShapeInsights listClusterQueryShapes](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-api-queryshapeinsights-listclusterqueryshapes.md#std-label-atlas-api-queryShapeInsights-listClusterQueryShapes) - Returns a list of query shapes for one cluster. [source]
- [atlas api queryShapeInsights listQueryShapeSummaries](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-api-queryshapeinsights-listqueryshapesummaries.md#std-label-atlas-api-queryShapeInsights-listQueryShapeSummaries) - Returns a list of query shape statistics summaries for a given cluster. [source]
- [atlas api queryShapeInsights updateClusterQueryShape](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-api-queryshapeinsights-updateclusterqueryshape.md#std-label-atlas-api-queryShapeInsights-updateClusterQueryShape) - Updates the rejection status of a query shape. [source]
A tailable cursor performs a collection scan over a [capped collection](https://www.mongodb.com/docs/manual/core/capped-collections.md#std-label-manual-capped-collection). It remains open even after reaching the end of the collection. Applications can continue to iterate the tailable cursor as new data is inserted into the collection. [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]
Including `$queryStats` output in the logs provides more information on specific `$queryStats` operations, but can negatively impact cluster performance as log updates take more time and resources. [source]
For an example of transformed `$queryStats` output, see [Transformed Example.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats.md#std-label-queryStats-example-transformed) [source]
The following entries show `$queryStats` output for `find`, `aggregate`, `update`, `insert`, and `delete` commands. [source]
In [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#std-program-mongosh), this command can also be run through the [`PlanCache.clear()`](https://www.mongodb.com/docs/manual/reference/method/plancache.clear.md#mongodb-method-PlanCache.clear) and [`PlanCache.clearPlansByQuery()`](https://www.mongodb.com/docs/manual/reference/method/plancache.clearplansbyquery.md#mongodb-method-PlanCache.clearPlansByQuery) helper methods. [source]
The [`planCacheListFilters`](https://www.mongodb.com/docs/manual/reference/command/plancachelistfilters.md#mongodb-dbcommand-dbcmd.planCacheListFilters) command returns the document with the following form: [source]
For instance, a [`query`](https://www.mongodb.com/docs/manual/reference/command/plancachelistfilters.md#mongodb-data-planCacheListFilters.filters.query) predicate of `{ "type": "electronics", "status" : "A" }` covers the following query predicates: [source]
Both the Atlas Query Profiler and the database profiler can affect server performance, use up disk space, and expose query metadata around encrypted fields. Consider the performance and security implications before enabling them. [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]
Are affected by slowOpSampleRate. [source]
<executionPart>SpilledRecords indicates the number of records written to temporary files on disk. [source]
The original query shape of the mongos operation may differ after the mongos sends the operation to the mongod . [source]
"planCacheShapeHash":"9C05019A", [source]
"planCacheKey":"C41063D6", [source]
"planCacheKey": "1D3DE690", [source]
Starting in MongoDB 6.3, a message is added to the log if the time to send an operation response exceeds the slowms threshold option. [source]
A session workflow message is added to the log if sendResponseMillis exceeds the slowms threshold option. [source]
For more information on how sharding works with aggregations, read the sharding chapter in the Practical MongoDB Aggregations e-book. [source]
A hexadecimal string that represents the hash of the [query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-shape). For more information, see [Query Shapes.](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) [source]
Number of queries executed per hour which match the query shape. [source]
Average execution time in milliseconds for queries which match the query shape. [source]
A session workflow message is added to the log if `sendResponseMillis` exceeds the [slowms threshold option.](https://www.mongodb.com/docs/manual/reference/command/profile.md#std-label-slowms-threshold-option) [source]
- [operation rejection filters](https://www.mongodb.com/docs/manual/tutorial/operation-rejection-filters.md#std-label-operation-rejection-filters) to block `find`, `aggregation`, and `distinct` commands that have a specified query shape. [source]
Deletes query settings previously added with [`setQuerySettings`.](https://www.mongodb.com/docs/manual/reference/command/setquerysettings.md#mongodb-dbcommand-dbcmd.setQuerySettings) [source]
For more information about query shapes, see [Query Shapes.](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) [source]
You can delete query settings using either of the following syntax specifications. [source]
The following example uses `$querySettings` to return the query settings: [source]
4. Delete the query settings [source]
```javascript db.adminCommand( { removeQuerySettings: "F42757F1AEB68B4C5A6DE6182B29B01947C829C926BCC01226BDA4DDE799766C" } ) ``` [source]
The Atlas Query Profiler supports binning operations of the same type running on the same collection around the same timestamp to support additional datapoints. [source]
**Important: Please read the following considerations before you enable the Query Profiler.** [source]
The Query Profiler displays approximately 100,000 sampled logs at a time. It shows all the logs if 100,000 or less logs were recorded in the selected hosts and time range. [source]
Atlas displays no more than 100,000 data points in the Query Profiler charts. [source]
The Query Profiler does not include bulk operations in its query sampling and analysis. Bulk write operations are excluded from the profiled queries displayed in the Query Profiler. Excluded operations include [`bulkWrite()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.bulkWrite.md#mongodb-method-db.collection.bulkWrite), `updateMany` with multiple `stmtIds`, and similar multi-document operations. [source]
Atlas enables the Query Profiler by default. [source]
2. Disable the Query Profiler. [source]
In the Database Monitoring Tools section, toggle Performance Advisor and Profiler to Off. [source]
The Query Profiler displays all your data from the log on the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) and [secondary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-secondary) nodes by default. [source]
3. Customize the Query Profiler. [source]
Select the time period from the Time Range or Filter by Date and Time dropdowns. The Query Profiler displays data for the last 24 hours by default. [source]
Click the All operation types dropdown to change which operations you want to profile. The Query Profiler displays all operation types by default. [source]
planCacheShapeHash: <hexadecimal string>, [source]
planCacheKey: <hexadecimal string>, [source]
explain.queryPlanner.querySettings [source]
explain.queryPlanner.planCacheShapeHash [source]
explain.queryPlanner.planCacheKey [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]
A hexadecimal string that represents the hash of the query shape. For more information, see Query Shapes. [source]
2. Toggle the button next to Performance Advisor and Profiler. [source]
docsExamined: 10000 cursorExhausted:1 numYields:234 [source]
Query Shape Reports, which send a summary of inefficient query shapes to Project Owners by email. [source]
The Query Profiler, which describes specific inefficient queries executed on the cluster. [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]
Returns a list of query shapes for one cluster. [source]
Query shapes may be filtered by their status; at present, this endpoint supports only the REJECTED status. [source]
The Query Profiler displays all your data from the log on the primary and secondary nodes by default. [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]
Plan cache entries have three states. Missing: no entry exists, so plans are evaluated and an Inactive placeholder with a work value is created. Inactive: placeholder, not used to generate plans. Active: used to generate plans. A newly selected plan whose work value is less than or equal to the placeholder's replaces it and becomes Active. If the value is greater, the placeholder stays and its value is incremented. An Active entry whose work no longer meets the selection criterion drops to Inactive. [source]
The plan cache is local to each mongod, with no cluster-wide cache. Shards and replica set members can therefore choose different plans for the same shape. [source]
A query shape groups similar queries by filters, sorts, projections, aggregation pipeline stages and namespace, ignoring literal values; queries with the same specification share one shape. [source]
Datadog's Atlas integration streams query shape metrics under the mongodb.atlas.querystats prefix with samplingstrategy (sampled | rate_limited) and samplingrate tags; M10+ only. [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]
Depending on the distribution of data in the cluster and the selectivity of the query, mongos may still perform a broadcast operation to fulfill these queries. [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]
Depending on the distribution of data in the cluster and the selectivity of the query, [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) may still perform a [broadcast operation](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md#std-label-sharding-mongos-broadcast) to fulfill these queries. [source]

Related concepts

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

Children

$natural hint and collection scans (frontier)
Atlas Performance Advisor index suggestions
Atlas Query Profiler and Performance Advisor
Atlas Query Shape Insights (frontier)
Atlas Query Targeting alerts
Equality-Sort-Range index ordering
Index filters deprecation and migration
Operation rejection filters
Persisting index usage metrics across restarts (PMM/monitoring) (frontier, viability 2.85 / 5, below research gate)
Replanning loops and replanReason
SBE vs classic plan cache keys
currentOp planSummary for running operations
hint in aggregate and update/delete
min()/max() requiring hint
planCacheSize and $planCacheStats
transformIdentifiers HMAC privacy mode
MongoDB Advanced Explain: Aggregation, Sharded Plans, Loose Index Scans and the 8.3 Cost-Based Ranker
natural hint and collection scans

Frontier under this node: $natural hint and collection scans, Atlas Query Shape Insights, Persisting index usage metrics across restarts (PMM/monitoring) (2.85)

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