MongoDB Wildcard and Hidden Indexes, Index Builds and Index Overhead

Parent: MongoDB Indexes Deep Dive · Published reference · snapshot 2026-10-19 · skill mongodb-expert/references/mongodb-special-indexes-and-index-builds.md

Also known as: Hidden Indexes, In-flight index builds, Index Build Conflicts and Commit Quorum and In-Flight Builds, Index Build Strategies, Index Storage and RAM Fit and Write-Path Overhead, Index build commit quorum (8.0 nuance), Index build conflicts, Wildcard Indexes, Wildcard and Compound Wildcard Indexes

↓ Facts as markdown all context files

Wildcard indexes index every scalar value under a path so queries on unknown field names can use an index, hidden indexes stay fully maintained but invisible to the planner, and index builds run as optimized hybrid builds that replica-set members vote to commit under a commit quorum; every index adds disk, cache and write cost. Compiled from MongoDB manual and Atlas pages plus the run's verified claims.

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

If a secondary node that is not included in the commit quorum receives a commitIndexBuild oplog entry, the node may block replication until its index build is complete. [source]
- If a hidden index is a [unique index](https://www.mongodb.com/docs/manual/core/index-unique.md#std-label-index-type-unique), the index still applies its unique constraint to the documents. [source]
- If a hidden index is a [TTL index](https://www.mongodb.com/docs/manual/core/index-ttl.md#std-label-index-feature-ttl), the index still expires documents. [source]
If a hidden index is a unique index, the index still applies its unique constraint to the documents. [source]
If a hidden index is a TTL index, the index still expires documents. [source]
- If the element is an object, the index descends into the object to traverse and index its contents. [source]
- If the element is a primitive value, the index records that value. [source]
If a field is a nested document or array, the wildcard index recurses into the document/array and indexes all scalar fields in the document/array. [source]
- If the field is an object, the wildcard index descends into the object and indexes its contents. The wildcard index continues descending into any additional embedded documents it encounters. [source]
- If the element is an object, the wildcard index descends into the object to index its contents. [source]
- If the element is an array (that is, an array which is embedded directly within the parent array), the wildcard index does not traverse the embedded array, but indexes the *entire* array as a single value. [source]
The document is not indexed if all of the fields in the compound wildcard index are missing. [source]
If a field is an embedded document or array (like `attributes.size`), the wildcard index recurses into the field and indexes all embedded scalar field values. [source]
Fitting hot indexes and the working set in RAM is a performance recommendation, not a strict requirement for most storage engines; MongoDB staff said the docs' 'must' should read 'should'. The In-Memory Storage Engine (Enterprise) does require all data to fit in inMemorySizeGB. [source]
Rolling index builds are an alternative to [default index builds.](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations) [source]
Make sure you are not performing [DDL operations](https://www.mongodb.com/docs/manual/reference/ddl-operations.md#std-label-ddl-operations) while conducting the rolling index build. [source]
An index build is not stopped if there is insufficient available disk space. [source]
If there are any key constraint violations, the index build fails. The primary aborts the index build and creates an associated "abortIndexBuild" oplog entry. [source]
Hidden indexes are not used to support queries. If you hide an index and observe substantial negative performance impact, consider keeping and unhiding the index so queries can resume using it. [source]
Additionally, if there is a collation on the index key, you can only ensure uniqueness if the collation is simple. [source]
If the `_id` field is not the shard key, the uniqueness constraint only applies to the shard that stores the document. This means that two or more documents can have the same `_id` value, provided they occur on different shards. [source]
In cases where the `_id` field is not the shard key, MongoDB expects applications to ensure the uniqueness of `_id` values across the shards, for example, by using a unique identifier to populate the `_id` field. [source]

Structure and components

For a sharded collection distributed across multiple shards, one or more shards may contain a chunk with duplicate documents. As such, the create index operation may succeed on some of the shards (that is, the ones without duplicates) but not on others (that is, the ones 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/program/mongos.md#mongodb [source]
You can create a text index that contains every document field with string data in a collection. These text indexes are called **wildcard text indexes**. Wildcard text indexes support [`$text`](https://www.mongodb.com/docs/manual/reference/operator/query/text.md#mongodb-query-op.-text) [queries](https://www.mongodb.com/docs/manual/core/text-search/on-prem.md#std-label-text-search-on-prem) on unknown, arbitrary, or dynamically generated fields. [source]
Only use wildcard text indexes when the fields you want to index are unknown or may change. Wildcard text indexes don't perform as well as targeted text indexes on specific fields. If your collection contains arbitrary field names that prevent targeted indexes, consider remodeling your schema to have consistent field names. To learn more about targeted indexes, see [Create Indexes to Support Your Queries.](https://www.mongodb.com/docs/manual/data-modeling/schema-design-process/create-indexes.md#std-label-create-indexes-to-support-queries) [source]
- You can include a wildcard text index as part of a compound text index. To learn more about compound text indexes, see [Create a Compound Text Index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/create-text-index.md#std-label-compound-text-index-example) [source]
An array that contains the names of the indexes that are currently being built on the collection. Once an index build completes, the index does not appear in the [`indexBuilds`.](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.indexBuilds) [source]
Consider a collection `products_catalog` where documents may contain a `product_attributes` field. The `product_attributes` field can contain arbitrary nested fields, including embedded documents and arrays: [source]
The index option `hidden` no longer appears as part of the `borough_1_ratings_1` index since the field is only returned if the value is `true`. [source]
MongoDB can only use a wildcard index to fulfill a given field path in the query if the path contains 8 or fewer explicit array indices. If the field path contains more than 8 explicit indices, to fulfill the query, MongoDB either: [source]
- Wildcard indexes are [sparse](https://www.mongodb.com/docs/manual/core/index-sparse.md#std-label-index-type-sparse). They only include entries for documents that contain the indexed field. [source]
- Create a wildcard index that omits specific fields. For example, if you have a collection that contains a field that is never queried, you can omit that field from the index. [source]
The following operation creates a wildcard index that contains all scalar values (meaning strings and numbers) of the `attributes.size` and `attributes.color` fields: [source]
Starting in MongoDB 5.0, the `wildcardProjection` option for [wildcard indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) is included in the [index signature](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-index-signature). This means that you can create multiple wildcard indexes with the same [key pattern](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindexes.md#std-label-key_patterns) as long as the `wildcardProjection` options do not contain the same fields. [source]
Only use wildcard indexes when the fields you want to index are unknown or may change. Wildcard indexes don't perform as well as targeted indexes on specific fields. If your collection contains arbitrary field names that prevent targeted indexes, consider remodeling your schema to have consistent field names. To learn more about targeted indexes, see Create Indexes to Support Your Queries. [source]
Wildcard indexes are sparse indexes and only contain entries for documents that have the indexed field, even if the index field contains a null value. [source]
Wildcard indexes have specific behavior when the indexed field contains an embedded object (for example, `attributes.secret_feature`). For more information, see [Wildcard Indexes on Embedded Objects and Arrays.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard/reference/embedded-object-behavior.md#std-label-wildcard-index-embedded-object-behavior) [source]
This index supports single-field queries on any field in the collection. If a document contains an embedded document or array, the wildcard index traverses the document or array and stores the value for all fields in the document or array. [source]
A compound wildcard index may contain only one wildcard term (e.g. { userID: 1, "object1.$**": 1, "object2.$**": 1 } is rejected), and its non-wildcard terms must be single-key; multikey (array) terms are not allowed. [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]
| Field | Type | Description | | --- | --- | --- | | `status` | string | The state of the index generation on the corresponding `mongot`. | | `queryable` | boolean | Indicates whether the index generation is ready to be queried on the corresponding `mongot`. | | `synonymMappingStatus` | string | The state of the index generation's synonym mappings on the corresponding `mongot`. Only present if the index has synonyms defined. | | `synonymMappingStatusDetails` | document | Contains the status of the index's synonym mappings on the corresponding `mongot`. This field (and its subfields) only appea [source]
Queryable Encryption always outputs a different encrypted value, even for the same input. The server considers each encrypted value unique, even though the decrypted value may not be. This means that even if a collection uses an index-enforced unique constraint on fields, the collection can still contain multiple documents with duplicate plaintext values for that field. [source]
If you drop an index that is actively used in production, your application may incur a performance degradation. To ensure queries can still use an index during modification, you can create a temporary, redundant index that contains the same fields as the modified index. [source]
Each index that the Performance Advisor suggests contains the following metrics. These metrics apply specifically to queries which would be improved by the index: [source]
The following example creates a pipeline stage that returns a document that contains usage statistics for each index on the collection. The example then runs the aggregation pipeline: [source]

How it works

In previous releases, when the primary committed the index build, the write concern specified how many nodes must finish the index build before the command returned success. [source]
The [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) marks index build as ready only after a simple majority of data-bearing voting members "vote" to commit the index build. For more information on index builds and the voting process, see [Index Builds in Replicated Environments.](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations-replicated-build) [source]
On replica sets and sharded clusters with featureCompatibilityVersion 4.4+, a build runs simultaneously on all data-bearing members (on sharded clusters only on shards holding the collection). The primary writes startIndexBuild, members vote when done scanning, and the primary writes commitIndexBuild after a commit quorum (default votingMembers) votes and no constraint violation is found; otherwise abortIndexBuild. [source]
You can resume some interrupted index builds when the commit quorum is set to the default "votingMembers". [source]
Index creation is a multistage process. The index creation process uses the commit quorum to minimize replication lag on secondary nodes. [source]
Changed in version 8.0: The commit quorum specifies how many nodes must be ready to finish the index build before the primary commits the index build. In contrast, when the primary has committed the index build, the write concern specifies how many nodes must replicate the index build oplog entry before the command returns success. [source]
If a primary or secondary mongod performs a clean shutdown with "force" : true or receives a SIGTERM signal during an index build, and the commitQuorum is set to the default votingMembers, the index build progress is saved to disk. The mongod automatically recovers the index build when restarted and continues from the saved checkpoint. [source]
If the mongod is the primary, it waits until it has a commit quorum of votes (all voting data-bearing members by default) before continuing the index build process. [source]
Index creation is a [multistage process](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-build-process). The index creation process uses the `commit quorum` to minimize replication lag on secondary nodes. [source]
5. When the primary has a quorum of votes, it checks for any key constraint violations such as duplicate key errors. [source]
- [Unique indexes](https://www.mongodb.com/docs/manual/core/index-unique.md#std-label-index-type-unique) Wildcard indexes are [sparse](https://www.mongodb.com/docs/manual/core/index-sparse.md#std-label-index-type-sparse) indexes. They do not support queries when an indexed field does not exist. A wildcard index will index the document if the wildcard field has a `null` value. [source]
After you create a wildcard text index, when you insert or update documents, the index updates to include any new string field values. As a result, wildcard text indexes negatively impact performance for inserts and updates. [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 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]
The index **does not** support queries on `attributes.memory`, because that field was omitted from the index. [source]
4. Secondary members continue to process any new write operations into the index while waiting for the primary to confirm a quorum of votes. [source]
Click the closed-eye icon on the right that appears when you hover over your selected index. [source]
Because indexes are fully maintained while hidden, the index is immediately available for use once unhidden. [source]
A community forum test reported that hiding an index on the primary also showed as hidden on a secondary, i.e. the hide replicates (anecdotal, single test). Because the toggle is a collMod oplog entry, it is expected to replicate. [source]
Wildcard indexes are sparse indexes. They do not support queries when an indexed field does not exist. A wildcard index will index the document if the wildcard field has a null value. [source]
Wildcard indexes do not support mixing inclusion and exclusion statements in the wildcardProjection document except when explicitly including the _id field. For more information on wildcardProjection, see the parameter documentation. [source]
The index records for `ship.coordinates` and `ship.captains` do not include the array position for each element. Wildcard indexes ignore array element positions when recording the element into the index. However, wildcard indexes can still support queries that include explicit array indices. [source]
Unfortunately, it is expensive to create a lot of individual indexes to cover all of the possible queries. A wildcard index is a good alternative to creating a large number of individual indexes because one wildcard index can efficiently cover many potential queries. [source]
When using `wildcardProjection` with compound wildcard indexes, the following rules apply: [source]
Wildcard indexes are intended for queries on fields whose names are unknown, vary between documents, or live in inconsistent embedded documents. MongoDB's manual says to use them only when the indexed fields are unknown or may change, and that they do not perform as well as targeted indexes on specific fields. [source]
When a secondary node receives a commitIndexBuild oplog entry, the node stops further oplog applications until the local index build can be committed. Index builds can take anywhere from moments to days to complete, so the replication lag can be significant if the secondary node builds more slowly than the primary. [source]
The commit quorum does not guarantee that indexes on secondaries are ready for use when the command completes. To ensure that a specific number of secondaries are ready for use, set an appropriate write concern. [source]
MongoDB begins removing expired documents or time series buckets as soon as the index finishes building on the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary). For more information on the index build process, see [Index Builds on Populated Collections.](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations) [source]
- To learn how MongoDB builds indexes, see [Index Build Process.](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-build-process) [source]
For featureCompatibilityVersion "4.2", createIndexes uses an optimized build process that obtains and holds an exclusive lock on the specified collection at the start and end of the index build. All subsequent operations on the collection must wait until createIndexes releases the exclusive lock. createIndexes allows interleaving read and write operations during the majority of the index build. [source]
For featureCompatibilityVersion "4.0", createIndexes uses the pre-4.2 index build process which by default obtains an exclusive lock on the parent database for the entire duration of the build process. The pre-4.2 build process blocks all operations on the database and all its collections until the operation completed. background indexes do not take an exclusive lock. [source]
When using the default maxNumActiveUserIndexBuilds of 3, the total memory usage for all concurrent index builds can reach up to three times the value of maxIndexBuildMemoryUsageMegabytes. [source]
The primary marks index build as ready only after a simple majority of data-bearing voting members "vote" to commit the index build. For more information on index builds and the voting process, see Index Builds in Replicated Environments. [source]
Applications may encounter reduced performance during index builds, including limited read/write access to the collection. For more information on the index build process, see [Index Builds on Populated Collections](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations), including the [Index Builds in Replicated Environments](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations-replicated-build) section. [source]
Building an index in a rolling fashion reduces the resiliency of your cluster and increases index build times. We only recommend using rolling index builds when regular index builds do not meet your needs. [source]
If you decide to continue with a rolling index, consider that they must meet certain conditions to succeed. To ensure your index build succeeds, avoid the following design patterns that commonly trigger a restart loop: [source]
Atlas automatically cancels rolling index builds that don't succeed on all nodes. When a rolling index build completes on some nodes, but fails on others, Atlas cancels the build and removes the index from any nodes that it was successfully built on. [source]
When an index build completes, Atlas generates an [activity feed event](https://www.mongodb.com/docs/atlas/tutorial/activity-feed.md#std-label-view-activity-feed) and sends a notification email to the project owner with the following information: [source]
If you increase `indexBuildMinAvailableDiskSpaceMB`, ensure your server has enough available disk space. Also, if you set `indexBuildMinAvailableDiskSpaceMB` too high, you might needlessly prevent index builds when there is enough available disk space and `indexBuildMinAvailableDiskSpaceMB` could be set lower. [source]
The following sections explain the index properties that you can specify when building an index. [source]
The preceding command ensures the correct set of shards is targeted for rolling index builds because no migration for the collection will be allowed to commit. [source]
When the index build completes, shutdown the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instance. Undo the configuration changes made when starting as a standalone to return to its original configuration and restart. [source]
For [featureCompatibilityVersion](https://www.mongodb.com/docs/manual/reference/command/setfeaturecompatibilityversion.md#std-label-view-fcv) `"4.2"`, [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.createIndexes) uses an optimized build process that obtains and holds an exclusive lock on the specified collection at the start and end of the index build. All subsequent operations on the collection must wait until [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.create [source]
For [featureCompatibilityVersion](https://www.mongodb.com/docs/manual/reference/command/setfeaturecompatibilityversion.md#std-label-view-fcv) `"4.0"`, [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.createIndexes) uses the pre-4.2 index build process which by default obtains an exclusive lock on the parent database for the entire duration of the build process. The pre-4.2 build process blocks all operations on the database *and* all its collections until the operation completed. `background` indexes do not take an exclusive lock. [source]
When using the default [`maxNumActiveUserIndexBuilds`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.maxNumActiveUserIndexBuilds) of `3`, the total memory usage for all concurrent index builds can reach up to three times the value of `maxIndexBuildMemoryUsageMegabytes`. [source]
Index builds use an optimized build process that holds an exclusive lock on the collection briefly at the beginning and end of the index build. The rest of the build process yields to interleaving read and write operations. For a detailed description of index build process and locking behavior, see Index Build Process. [source]
Index builds now obtain an exclusive lock on the collection being indexed only at the start and end of the build. The rest of the build process uses the yielding behavior of background index builds to maximize read-write access to the collection during the build. Index builds still produce efficient index data structures despite the more permissive locking behavior. [source]
The optimized index build performance is at least on par with background index builds. For workloads with few or no updates received during the build process, optimized index builds can be as fast as a foreground index build on that same data. [source]
Building indexes when the target collection is under heavy write load can result in reduced write performance and longer index builds. [source]
For a more detailed description of the index build process, see Index Build Process. [source]
The mongod can perform the startup process while recovering index builds. [source]
Starting in MongoDB 5.0, if a node is rolled back to a prior state during the index build, the index build progress is saved to disk. If there is still work to be done when the rollback concludes, the mongod automatically recovers the index build and continues from the saved checkpoint. [source]
The msg field includes a percentage-complete measurement of the current stage in the index build process. [source]
If the mongod replicates a "commitIndexBuild" oplog entry, it finishes draining the side writes table and moves to the next stage in the index build process. [source]
The S and X locks at the end of the index build are held only while the mongod drains the remaining side writes and finalizes the index, so they are typically brief. The duration depends on the number of writes remaining in the side writes table when each stage begins. [source]
Total number of index builds that failed because of data corruption. [source]
Rolling indexes may negatively impact your deployment. For information on when to use this index build, see [Rolling Index Builds.](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md#std-label-rolling-index-build) [source]
For a more detailed description of the index build process, see [Index Build Process.](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-build-process) [source]
The [`msg`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/currentop.md#mongodb-data--currentOp.msg) field includes a percentage-complete measurement of the current stage in the index build process. [source]
When the index build completes, shutdown the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instance. To return the node to its original configuration, undo the configuration changes that you made when you started the node as a standalone. Then, restart the node as a member of the replica set. [source]
The commit quorum does not guarantee that indexes on secondaries are ready for use when the command completes. To ensure that a specific number of secondaries are ready for use, set an appropriate [write concern.](https://www.mongodb.com/docs/manual/reference/write-concern.md#std-label-write-concern) [source]
Because a hidden index is fully maintained, unhiding takes effect immediately with no rebuild. Dropping an index, by contrast, requires a full rebuild to undo. [source]
Since MongoDB 4.2 all index builds use one optimized process: an exclusive X lock on the collection only at the start and end, with the middle phase downgraded to IX and yielding to reads and writes. The old foreground/background distinction is gone and the `background` option is ignored. [source]
- When a user is creating an index across the shards in a [rolling manner (i.e. manually building the index one by one across the shards)](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-sharded-clusters.md) but either fails to build the index for an associated shard or incorrectly builds an index with different specification. [source]
- Changing the `expireAfterSeconds` parameter **does not** trigger a complete index rebuild. However, reducing the `expireAfterSeconds` value can make many documents eligible for immediate deletion, potentially causing performance issues due to the increased delete operations. [source]
For example, consider a sharded collection with shard key `{x: 1}` that spans two shards A and B. Because the `_id` key is not the shard key, the collection could have a document with `_id` value `1` in shard A and another document with `_id` value `1` in shard B. [source]
When creating an index across the shards in a rolling manner (that is, manually building the index one by one across the shards) but either fails to build the index for an associated shard or incorrectly builds an index with different specification. [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]
In clustered collections with only a default index on the `_ìd` field (no secondary indexes), the index size appears as zero because the collection does not require a separate index file. [source]
You can only use a `wildcardProjection` when the wildcard term is `$**`. [source]
- The following `wildcardProjection` document is **invalid** because it specifies both an inclusion and an exclusion of a field: [source]
- The following `wildcardProjection` document is **valid** because even though it specifies both inclusion and exclusion, it includes the `_id` field: [source]
- When a user is creating an index across the shards in a rolling manner but either fails to build the index for an associated shard or incorrectly builds an index with different specification. [source]
Storage engine configuration options specified when creating indexes are validated and logged to the oplog during replication to support replica sets with members that use different storage engines. [source]

How-to and procedures

To set the [commit quorum](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#std-label-createIndexes-cmd-commitQuorum), use [`createIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindexes.md#mongodb-method-db.collection.createIndexes) to specify the `commitQuorum` value. [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 manage the replication lag, the commit quorum delays committing the index build on the primary node until a minimum number of secondaries are also ready to commit the index build. [source]
To start an index build with a non-default commit quorum, specify the commitQuorum. [source]
Use the setIndexCommitQuorum command to modify the commit quorum of an in-progress index build. [source]
To start an index build with a non-default commit quorum, specify the [commitQuorum.](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#std-label-createIndexes-cmd-commitQuorum) [source]
To modify the commit quorum required for an in-progress simultaneous index build, use the [`setIndexCommitQuorum`](https://www.mongodb.com/docs/manual/reference/command/setindexcommitquorum.md#mongodb-dbcommand-dbcmd.setIndexCommitQuorum) command. [source]
To hide a text index, you must specify the index by `name` and not by `keyPattern`. [source]
To create a wildcard text index, set the index key to the wildcard specifier (`$**`) and set the index value to `text`: [source]
Create a wildcard text index on the `blog` collection: [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 drop or hide an index by using the Atlas UI, click the Indexes tab, then click the Drop Index or Hide Index icon next to the index. Atlas displays a dialog box to confirm your selection. For more information, see [Manage Atlas Indexes.](https://www.mongodb.com/docs/atlas/atlas-ui/indexes.md#std-label-atlas-ui-indexes) [source]
To create a `hidden` index, use the [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindex.md#mongodb-method-db.collection.createIndex) method with the [hidden](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindex.md#std-label-method-createIndex-hidden) option set to `true`. [source]
To use the `hidden` option with [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindex.md#mongodb-method-db.collection.createIndex), 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 verify, run [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getindexes.md#mongodb-method-db.collection.getIndexes) on the `restaurants` collection: [source]
Create a Wildcard Index on a Single Field Path [source]
Create a Wildcard Index on All Field Paths [source]
Create a Wildcard Index on Multiple Specific Field Paths [source]
Create a Wildcard Index that Excludes Multiple Specific Field Paths [source]
Create a wildcard index that includes the `ship` field: [source]
To create a [partial](https://www.mongodb.com/docs/manual/core/index-partial.md#std-label-index-type-partial) compound wildcard index, you can use the `partialFilterExpression` option to specify a filter expression so that the index only includes documents that match the filter condition. `partialFilterExpression` can cover fields included or not included in the index. [source]
To include or exclude fields in a wildcard index, specify the chosen fields in the `wildcardProjection` option: [source]
To learn how to use wildcard projection with a compound wildcard index to filter fields, see [Filter Fields with a `wildcardProjection`.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard/index-wildcard-compound.md#std-label-wc-compound-index-wcProject) [source]
To learn how to specify a wildcard index, see [Create a Wildcard Index.](https://www.mongodb.com/docs/atlas/atlas-ui/indexes.md#std-label-atlas-ui-wildcard-index) [source]
To create a wildcard index on a single field, use the [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindex.md#mongodb-method-db.collection.createIndex) method and include the wildcard specifier (`$**`) in the index key: [source]
To create a wildcard index on all fields (excluding `_id`), use the wildcard specifier (`$**`) as the index key: [source]
Use [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) to monitor index creation. [source]
To unhide the index, you can specify either the index key specification document or the index name to the [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideindex.md#mongodb-method-db.collection.unhideIndex) method. The following specifies the index name: [source]
To hide or unhide existing indexes, you can use the following [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) methods: [source]
Avoid performing rolling index and replicated index build processes concurrently as it might lead to unexpected issues, such as broken builds and crash loops. [source]
Use db.currentOp() to monitor the progress of ongoing index builds. [source]
To see the status of an index build operation, you can use the db.currentOp() method in mongosh. To filter the current operations for index creation operations, see Active Indexing Operations for an example. [source]
To hide an index, you must have featureCompatibilityVersion set to 7.0 or greater. [source]
To hide the index, you can specify either the index key specification document or the index name to the db.collection.hideIndex() method. The following specifies the index name: [source]
Use [`db.currentOp()`](https://www.mongodb.com/docs/manual/reference/method/db.currentop.md#mongodb-method-db.currentOp) to monitor the progress of ongoing index builds. [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 unhide your index, repeat steps 1-3. After you unhide your index, Atlas removes the Hidden badge from the Properties column. [source]
To drop or hide an index by using the MongoDB Shell, paste and run the command provided by the Performance Advisor. [source]
Run the following command on your primary to unhide the secondary node that built the index. In this example, the secondary node that built the index is the third node in `cfg.members`. [source]
To unhide your index, repeat steps 1-3. After you unhide your index, Compass removes the Hidden badge from the Properties column. [source]
To hide an existing index, you can use the [`collMod`](https://www.mongodb.com/docs/manual/reference/command/collmod.md#mongodb-dbcommand-dbcmd.collMod) command or [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) helper [`db.collection.hideIndex()`.](https://www.mongodb.com/docs/manual/reference/method/db.collection.hideindex.md#mongodb-method-db.collection.hideIndex) [source]
To unhide a hidden index, you can use the [`collMod`](https://www.mongodb.com/docs/manual/reference/command/collmod.md#mongodb-dbcommand-dbcmd.collMod) command or [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) helper [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideindex.md#mongodb-method-db.collection.unhideIndex). You can specify either: [source]
To create a hidden index, use the db.collection.createIndex() method with the hidden option set to true. [source]
Create a unique compound [multikey](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md#std-label-index-type-multikey) index on `a.loc` and `a.qty`: [source]
Create a unique compound [multikey](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md#std-label-index-type-multikey) index on `email` and `name`: [source]
To maintain uniqueness on a field that is not your shard key, see [Unique Constraints on Arbitrary Fields.](https://www.mongodb.com/docs/manual/tutorial/unique-constraints-on-arbitrary-fields.md#std-label-shard-key-arbitrary-uniqueness) [source]
Use the [`collMod`](https://www.mongodb.com/docs/manual/reference/command/collmod.md#mongodb-dbcommand-dbcmd.collMod) command to update any misconfigured `expireAfterSeconds` values that the script found. [source]
Use the [`$indexStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats) aggregation stage to get statistics regarding the use of each index for a collection. For example, the following aggregation operation returns statistics on the index use on the `orders` collection: [source]
Create an index for the specified cluster for your project. Atlas builds the index in a rolling manner. [source]
To set the commit quorum, use createIndexes to specify the commitQuorum value. [source]

Examples and snippets

```javascript — `db.salesData.dropIndex( "tenant_customFields" )` … [source]
```javascript — `ok: 1,` … [source]
```javascript — `ok: 1,` … [source]
```javascript — `_id: ObjectId("<object-id>"),` … [source]
```javascript — `db.products_catalog.find( { "product_attributes.washable" : true } )` … [source]
```bash — `use inventory` … [source]
```bash — `use inventory` … [source]
```javascript — `db.salesData.createIndex(` … [source]
```javascript — `db.runCommand(` … [source]
```bash — `use inventory` … [source]
```bash — `db.products_catalog.find( { "product_attributes.superFlight" : true } )` … [source]
```bash — `use inventory` … [source]
```bash — `use inventory` … [source]
```bash — `use inventory` … [source]
```json — `indexStats: {` … [source]
```javascript — `db.getSiblingDB("examples").runCommand(` … [source]
```javascript — `"v" : 2,` … [source]
```javascript — `"v" : 2,` … [source]
```javascript — `ok: 1,` … [source]
```javascript — `ok: 1,` … [source]
```javascript — `localTime : 2020-03-06T01:44:57.437Z,` … [source]
```javascript — `ns: 'sample_mflix.nonExistentCollection',` … [source]
```javascript — `"ns" : <string>,` … [source]
```javascript — `db.runCommand(` … [source]
```javascript — `db.runCommand(` … [source]
```javascript — `db.runCommand( {` … [source]
```javascript — `db.movies.stats( { indexDetails : true } )` … [source]
```javascript — `db.movies.stats(` … [source]
```javascript — `db.<collection>.dropIndex("<indexName>")` … [source]
```javascript — `db.<collection>.dropIndexes( [ "<index1>", "<index2>", "<index3>" ] )` … [source]
```javascript — `db.<collection>.dropIndexes()` … [source]
```javascript — `db.collection.unhideIndex(<index>)` … [source]
```sh — `Too many index builds running simultaneously, waiting until the` … [source]
```javascript — `db.runCommand(` … [source]
```bash — `"msg":"Index build: wrote resumable state to disk",` … [source]
```javascript — `db.runCommand( {` … [source]
```javascript — `db.getSiblingDB("admin").aggregate( [` … [source]
```javascript — `db.createCollection(` … [source]
```javascript — `db.runCommand({` … [source]
```javascript — `db.users.createIndex(` … [source]
```javascript — `db.movies.createIndex( { title: 1, runtime: "hashed" } )` … [source]
```javascript — `db.collection.createIndex( <key and index type specification>, { unique: true } )` … [source]
```javascript — `db.<collection>.createIndex( { "$**": "text" } )` … [source]
```javascript — `db.blog.createIndex( { "$**": "text" } )` … [source]
```javascript — `"wildcardProjection": {` … [source]
```javascript — `db.products.createIndex( { "product_attributes.$**" : 1 } )` … [source]
```javascript — `db.collection.createIndex(` … [source]
```javascript — `db.<collection>.createIndex(` … [source]
```javascript — `db.books.createIndex(` … [source]
```javascript — `{ v: 2, key: { _id: 1 }, name: '_id_' },` … [source]
```javascript — `db.artwork.createIndex( { "$**" : 1 } )` … [source]
```javascript — `raw: {` … [source]
```javascript — `db.collection.createIndex( <keys>, <options>, <commitQuorum> )` … [source]

Measurements and reference values

With the default votingMembers quorum, an unreachable data-bearing voting member makes the createIndexes hang until it returns. Percona's test (3-node, one down) ran about 4,678 s; the index was listed by getIndexes() but unusable and queries used COLLSCAN. With 'majority' the same build finished in about 2.5 s. [source]
MongoDB advises rolling builds only if average CPU exceeds (N-1)/N - 10% (N = CPU threads available to mongod) or WiredTiger cache fill regularly exceeds 90%; otherwise use the default build. Rolling builds lower cluster resiliency, increase build duration, require at least one election, and are not supported on Atlas Infinite clusters. [source]

Problems, failure modes and limitations

| 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]
| Option | Description | More Information | | --- | --- | --- | | Create unique index | Ensure that the indexed fields do not store duplicate values. You cannot perform a rolling build for a unique index. If you enable building indexes in a rolling fashion with the `unique` index option, Atlas rejects your configuration with an error message. | [Unique Indexes](https://www.mongodb.com/docs/manual/core/index-unique/) | | Index name | Specify a name for the index. | [Specify an Index Name](https://www.mongodb.com/docs/manual/core/indexes/create-index/specify-index-name.md#std-label-specify-index [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]
Wildcard indexes cannot be unique, TTL, text, hashed, 2d or 2dsphere, cannot serve $text queries, and cannot be a shard key index. They are sparse: they do not index documents missing the field (null values are indexed), so they cannot serve { field: { $exists: false } }. [source]
commitQuorum accepts 'votingMembers' (default, all data-bearing voting members), 'majority', a positive integer, a replica-set tag name, or 0. Nodes with buildIndexes:false cannot be in a quorum, so if any voting node has buildIndexes:false the default votingMembers cannot be used. [source]
Commit quorum is not write concern. It does not guarantee secondary indexes are usable when createIndexes returns. A secondary receiving commitIndexBuild stops applying further oplog entries until its local build commits, so slow builds on secondaries (including ones outside the quorum) cause replication lag. Since 8.0 write concern controls how many nodes must replicate the commitIndexBuild entry before success returns; before 8.0 it controlled how many nodes had finished building. [source]
Interrupted builds resume from a checkpoint only after a clean shutdown (force:true or SIGTERM) with commit quorum votingMembers. A crash restarts the build from the beginning, and a checkpoint resume works only once per build. Restarting as a standalone cannot restart the build. [source]
maxNumActiveUserIndexBuilds caps concurrent index builds; builds beyond the limit block until the count drops. [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]
| 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]
| 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]
| 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]
For a unique index, the rolling procedure requires stopping all writes to the collection for the duration; otherwise members can diverge. If writes cannot be stopped, run createIndex on the primary instead. [source]
createIndexes supports building one or more indexes on a collection. createIndexes uses a combination of memory and temporary files on disk to build indexes. In self-hosted MongoDB deployments, the default value of the maxIndexBuildMemoryUsageMegabytes parameter is 200 megabytes per createIndexes command. createIndexes shares the memory limit equally among all the indexes it builds. For example, if you build 10 indexes with one createIndexes command, MongoDB allocates each index 20 megabytes for the index build process. When you reach the memory limit, MongoDB creates temporary files in the _t [source]
Wildcard Indexes are distinct from and incompatible with [Create a Wildcard Text Index on Self-Managed Deployments](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/create-wildcard-text-index.md#std-label-create-wildcard-text-index). Wildcard indexes cannot support queries using the [`$text`](https://www.mongodb.com/docs/manual/reference/operator/query/text.md#mongodb-query-op.-text) operator. [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]
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]
Wildcard indexes are distinct from and incompatible with wildcard text indexes. Wildcard indexes cannot support queries using the $text operator. [source]
1. To create [unique indexes](https://www.mongodb.com/docs/manual/core/index-unique.md#std-label-index-type-unique) using the following procedure, you must stop all writes to the collection during the index build. Otherwise, you may end up with inconsistent data across the replica set members. If you cannot stop all writes to the collection, do not use the following procedure to create unique indexes. [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]
For indexes that enforce constraints on the collection, such as unique indexes, the mongod checks all pre-existing and concurrently-written documents for violations of those constraints after the index build completes. Documents that violate the index constraints can exist during the index build. If any documents violate the index constraints at the end of the build, the mongod terminates the build and throws an error. [source]
For example, consider a populated collection inventory. An administrator wants to create a unique index on the product_sku field. If any documents in the collection have duplicate values for product_sku, the index build can still start successfully. If any violations still exist at the end of the build, the mongod terminates the build and throws an error. [source]
If a document has a `null` or missing value for the indexed field in a unique single-field index, the index stores a `null` value for that document. Because of the unique constraint, a single-field unique index can only contain one document that contains a `null` value in its index entry. If there is more than one document with a `null` value in its index entry, the index build fails with a duplicate key error. [source]
The pattern `"$**"` includes all fields in the document. Use the `wildcardProjection` field to limit the index to the specified fields. [source]
If you want to compare the shell commands and the database commands, you must drop the indexes between command invocations. You cannot create the same index twice, even with different names. [source]
Existing indexes that do not meet the new validation requirements continue to function, but you cannot create new indexes that don't meet these requirements. [source]
| Rule | Valid Example | Invalid Example | | --- | --- | --- | | If you specify a `wildcardProjection`, it cannot be empty. | `{ productId: 1, "$**": 1 }, { wildcardProjection: { attributes: 1 } }` | `{ productId: 1, "$**": 1 }, { wildcardProjection: { } }` | | You can only combine inclusions and exclusions in a `wildcardProjection` if the included or excluded field is `_id`. You can exclude `_id` in inclusion projections or include `_id` in exclusion projections. | `{ "$**": 1, category: 1 }, { wildcardProjection: { _id: 0, attributes: 1 } }` `{ "$**": 1, category: 1 }, { wildcardProjection: [source]
The pattern `"$**"` includes all fields in the document. Use the `wildcardProjection` field to limit the index to fields you specify. For complete documentation on `wildcardProjection`, see [Options for `wildcard` indexes.](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindex.md#std-label-createIndex-method-wildcard-option) [source]
You cannot specify a unique constraint on a [hashed index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed.md#std-label-index-type-hashed) [source]
On MongoDB Atlas, the default values of `maxIndexBuildMemoryUsageMegabytes` and `maxNumActiveUserIndexBuilds` vary by cluster tier. You cannot modify `maxIndexBuildMemoryUsageMegabytes` on MongoDB Atlas. [source]
Allows users to include or exclude specific field paths from a wildcard index using the { "$**" : 1} key pattern. This option is only valid if creating a wildcard index on all document fields. You cannot specify this option if creating a wildcard index on a specific field path and its subfields, e.g. { "path.to.field.$**" : 1 } [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]
Wildcard indexes themselves do not have limits on the depth to which they traverse a document while indexing it. The limitation only applies to queries which explicitly specify exact array indices. [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]
{ "userID":, "$**": 1 } ` However, you can't define an index that includes the same field in the wildcard fields and the regular (non-wildcard) fields. To define the index correctly, use a `wildcardProjection` to exclude duplicated fields from the wildcard pattern. `wildcardProjection` does not work with a specification like: `{ "path.to.field.$**": 1 }` The `wildcardProjection` option takes the following form: `wildcardProjection: { "path.to.field.a" : <value>, "path.to.field.b" : <value> }` The `<value>` can be either of the following: `1` or `true` to include the field in the wildcard inde [source]
Use a compound wildcard index instead. The compound wildcard index is easier to write, easier to maintain, and is unlikely to reach the 64 index collection limit. [source]
- You can only specify the `wildcardProjection` option when the wildcard field is `$**`. You cannot use `wildcardProjection` when you specify a field path for the wildcard index term. [source]
You cannot create the following index types using wildcard syntax (`$.**`): [source]
You cannot use a wildcard index as a [shard key index.](https://www.mongodb.com/docs/manual/core/sharding-shard-key-indexes.md#std-label-sharding-shard-key-indexes) [source]
If a given field is an array in any document in the collection, wildcard indexes cannot support queries for documents where that field is not equal to `null`. [source]
For example, consider an `inventory` collection with a wildcard index on `product_attributes`. The wildcard index **cannot** support the following queries if `product_attributes.tags` is an array in any document in the collection: [source]
Wildcard indexes store entries for the contents of a document or array, not the document or array itself. Therefore, wildcard indexes cannot support exact equality matches on documents or arrays. [source]
For example, consider an `inventory` collection with a wildcard index on `product_attributes`. The wildcard index cannot support the following queries: [source]
Similarly, wildcard indexes cannot support exact **inequality** matches on documents and arrays. For example, a wildcard index on `product_attributes` cannot support the following queries: [source]
Wildcard indexes are [sparse](https://www.mongodb.com/docs/manual/core/index-sparse.md#std-label-index-type-sparse) and do not index empty fields. Therefore, wildcard indexes cannot support queries for documents where a field does not exist. [source]
For example, consider an `inventory` collection with a wildcard index on `product_attributes`. The wildcard index cannot support all of the predicates in the following query: [source]
If the above conditions are not met, MongoDB cannot use the wildcard index for the sort. MongoDB does not support [`sort()`](https://www.mongodb.com/docs/manual/reference/method/cursor.sort.md#mongodb-method-cursor.sort) operations that require a different index from that of the query predicate. [source]
wildcardProjection works only when the wildcard term is $** (not a path like someFields.$**). Wildcard indexes omit _id by default; include it with $** or by adding _id: 1 to wildcardProjection. A field cannot appear both in the wildcard pattern and as a regular compound term; use exclusions in wildcardProjection to remove it. [source]
Starting in MongoDB 8.3, 8.2.4, 8.0.18 and 7.0.29, stricter wildcardProjection validation applies to compound wildcard indexes: projection cannot be empty; inclusions and exclusions cannot be mixed except for _id; included fields cannot overlap regular index fields; an _id-only exclusion needs _id as a regular index field; an exclusion projection must exclude all regular index fields. Existing non-compliant indexes keep working; new ones cannot be created. [source]
Wildcard indexes store the contents of documents and arrays, not the containers, so exact equality or inequality on a whole embedded document or array (e.g. { "product_attributes": { price: 29.99 } }) is unsupported (matching {} is the exception). If a field is an array in any document, the index cannot support $ne null on it. [source]
Consolidating many single-field indexes into one wildcard index helps stay under the 64-index-per-collection limit. A collection may hold several wildcard indexes and they may overlap other indexes. Compound wildcard indexes are sparse: a document is indexed if it has at least one of the compound fields. [source]
For replica sets and sharded clusters, using a [rolling procedure](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets.md#std-label-index-build-on-replica-sets) to create a unique index requires that you stop all writes to the collection during the procedure. If you cannot stop all writes to the collection during the procedure, do not use the rolling procedure. Instead, to build your unique index on the collection you must either: [source]
In self-hosted MongoDB deployments, you can change the memory limit for index builds by setting the maxIndexBuildMemoryUsageMegabytes parameter. Increasing this parameter is only necessary in rare cases. Such cases include running many simultaneous index builds with a single createIndexes command or indexing a data set larger than 500GB. You can also set maxNumActiveUserIndexBuilds to adjust how many index builds can run concurrently. [source]
For workloads which cannot tolerate performance decrease due to index builds, consider building indexes in a rolling fashion. [source]
A new index build cannot be started and a current index build is cancelled if the available disk space is below `indexBuildMinAvailableDiskSpaceMB`. [source]
Limits the amount of memory that simultaneous [index builds](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-build-process) on one collection may consume for their duration. The specified amount of memory is shared between all indexes built using a single [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.createIndexes) command or its shell helper [`db.collection.createIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindexes.md#mongodb-method-db.collection.createIndexes) [source]
Sets the maximum number of index build requests that MongoDB can perform concurrently. `maxNumActiveUserIndexBuilds` is a global limit that applies for all collections. [source]
System indexes are not limited to `maxNumActiveUserIndexBuilds`, however a system index build counts against the limit for user index builds. [source]
After the server reaches `maxNumActiveUserIndexBuilds`, it blocks additional user index builds until the number of concurrent index builds drops below the `maxNumActiveUserIndexBuilds` limit. If an index build is blocked, the server logs this message: [source]
The following command sets a limit of 4 concurrent index builds: [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]
- 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]
Rolling indexes build indexes on the applicable nodes sequentially and may reduce the performance impact of an index build if your deployment's average CPU utilization exceeds (N-1)/N-10% where N is the number of CPU threads available to mongod of if the WiredTiger cache fill ratio regularly exceeds 90%. If your deployment does not meet this criteria, use the default index build. You can't create a rolling index on an M0 free cluster or M2/M5 shared cluster. [source]
Starting in MongoDB 7.1, index builds are improved with faster error reporting and increased failure resilience. You can also set the minimum available disk space required for index builds using the new [`indexBuildMinAvailableDiskSpaceMB`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.indexBuildMinAvailableDiskSpaceMB) parameter, which stops index builds if disk space is too low. [source]
- You cannot hide a clustered index. See [Hidden indexes.](https://www.mongodb.com/docs/manual/core/index-hidden.md) [source]
Increased resilience for your deployment. If an index build error occurs, a secondary member can request that the primary member stop an index build and the secondary member does not crash. A request to stop an index build is not always possible: if a member has already voted to commit the index, then the secondary cannot request that the index build stop and the secondary crashes (similar to MongoDB 7.0 and earlier). [source]
An index build error can cause a secondary member to crash. [source]
If the number of concurrent index builds reaches the limit specified by maxNumActiveUserIndexBuilds, the server blocks additional index builds until the number of concurrent index builds drops below the limit. [source]
If no keys in the constraint violation table produce a key generation error or if the table is empty, the mongod drops the table and creates a "commitIndexBuild" oplog entry. Secondaries can complete the associated index build after replicating the oplog entry. [source]
If any key in the constraint violation table still produces a key generation error, the mongod aborts the build and throws an error. The mongod creates an associated "abortIndexBuild" oplog entry to indicate that secondaries should abort and discard the index build job. [source]
The [`maxIndexBuildMemoryUsageMegabytes`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.maxIndexBuildMemoryUsageMegabytes) limit applies to all index builds initiated by user commands like [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.createIndexes) or administrative processes like [initial sync.](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-sync) [source]
An [initial sync](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-sync) populates only one collection at a time and has no risk of exceeding the memory limit. However, it is possible for a user to start index builds on multiple collections in multiple databases simultaneously. [source]
Hidden indexes are not visible to the query planner and cannot be used to support a query. [source]
You cannot cursor.hint() a hidden index. [source]
Restrictions: the _id index cannot be hidden, and cursor.hint() cannot force a hidden index. [source]
Self-hosted index builds default to maxIndexBuildMemoryUsageMegabytes=200 per createIndexes command, split equally across the indexes in that command, spilling to _tmp under --dbpath. With the default maxNumActiveUserIndexBuilds=3, total can reach 3x. Raising it is rarely needed (many indexes in one command, or data over 500GB). On Atlas the defaults vary by tier and maxIndexBuildMemoryUsageMegabytes cannot be changed. [source]
- Other [`findAndModify`](https://www.mongodb.com/docs/manual/reference/command/findandmodify.md#mongodb-dbcommand-dbcmd.findAndModify) operations either update the newly-inserted document or fail due to a unique key collision. [source]
- Other [`findOneAndUpdate()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.findoneandupdate.md#mongodb-method-db.collection.findOneAndUpdate) operations either update the newly-inserted document or fail due to a unique key collision. [source]
Queryable Encryption compatible drivers configured for automatic encryption [support some operations for automatic encryption](https://www.mongodb.com/docs/manual/core/queryable-encryption/reference/supported-operations.md#std-label-qe-reference-automatic-encryption-supported-operations). For unsupported read and write operations, the underlying library can't introspect the index catalog to identify a given field as unique. Applications can't rely on automatic encryption validation to prevent unique constraint violations on randomly-encrypted fields. [source]
- **Remove the failed index**: Atlas removes the index entirely, and you must rebuild it. This happens when the index cannot be recovered. [source]
To update the commitQuorum, member replica set nodes must have members[n].buildIndexes set to true. If any voting nodes have members[n].buildIndexes set to false, you can't use the default "votingMembers" commit quorum. Either configure all nodes with members[n].buildIndexes set to true, or select a different commit quorum. [source]
Replica set nodes with buildIndexes set to false can't be included in a commit quorum. [source]
Replica set nodes with [buildIndexes](https://www.mongodb.com/docs/manual/reference/replica-configuration.md#std-label-replica-set-configuration-buildIndexes) set to `false` can't be included in a commit quorum. [source]

Comparisons and alternatives

| 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]
| 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]
Index builds take exclusive X locks only at start and end, plus a shared S lock during the final side-writes drain. These blocks cover reads, writes, replicated writes and metadata commands on the collection. Writes during the build are held in a side writes table, and key-constraint violations are recorded and checked at commit time rather than rejecting writes. [source]
If the mongod crashes instead of shutting down cleanly, the index build cannot resume regardless of the commit quorum setting. The index build restarts from the beginning when the mongod comes back online. [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]
If, however, the impact is negative, the user 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]
MongoDB 7.1 added early error reporting during the collection scan (except duplicate keys), a secondary can ask the primary to abort a failing build instead of crashing (unless it already voted to commit), and indexBuildMinAvailableDiskSpaceMB can stop builds when free disk is low; earlier versions do not stop on low disk. [source]
When a wildcard index encounters an array, it traverses the array to index its elements. If the array element is itself an array (an embedded array), the index records the *entire* embedded array as a value instead of traversing its contents. [source]
Azure Cosmos DB for MongoDB diverges: its docs say wildcard indexes there can support multiple fields in query predicates with no performance difference versus per-property indexes, but they cannot be compound, TTL or unique, and cannot use wildcardProjection with multiple specific fields (include or exclude). Cosmos advises individually indexed paths for write-heavy workloads because wildcard indexing of many-field documents raises write RU charges. Do not assume Cosmos behavior matches MongoDB Server. [source]
You can use hidden indexes to evaluate the potential impact of dropping an index without actually dropping it. If the impact is negative, you can unhide the index instead of having to recreate a dropped index. Hidden indexes are fully maintained and can be used immediately once unhidden. [source]
Index build errors can take a long time to be returned compared to MongoDB 7.1 because the errors are returned near the end of the index build in the commit phase. [source]
This differs from interrupted index builds on Atlas Core clusters and self-managed deployments, which are described in the following sections. [source]
An index build can resume from a saved checkpoint only once. If the mongod restarts again while that same index build is still in progress, the build restarts from the beginning instead of resuming from a checkpoint. [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 hidden index is not visible to the query planner and cannot support a query. Hiding it lets you evaluate the impact of dropping the index without dropping it; if the impact is negative, you unhide it instead of rebuilding it. [source]
Starting in version 6.0, you can add a secondary index to any field in a time series collection. MongoDB indexes time series collections by [buckets](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-bucketing.md#std-label-timeseries-bucketing) of documents as opposed to individual documents. Time series buckets contain documents with shared metaField values, ordered by timeField values that are close together. MongoDB indexes the minimum and maximum values of all fields, except the metaField. Indexing buckets instead of individual documents reduces index size and improves query e [source]

Facts and statements

Stop an in-flight build with dropIndexes (or dropIndex helpers), not killOp: the docs say not to use killOp on replica sets or sharded clusters. dropIndexes aborts the build via abortIndexBuild, and it must name every index from the same createIndexes batch. Percona's post instead says killOp cancels the build, which conflicts with the docs. [source]
Interrupted builds: on a replica set with default commit quorum, a clean shutdown or SIGTERM saves progress and the build resumes once from the checkpoint (since 5.0 also across rollbacks); a crash restarts from scratch. A member restarted as standalone leaves the build paused until dropped. A standalone mongod loses the build entirely. Use dropIndexes, not killOp, to stop a replicated build. [source]
| Option | Description | More Information | | --- | --- | --- | | Create unique index | Ensure that the indexed fields do not store duplicate values. | [Unique Indexes](https://www.mongodb.com/docs/manual/core/index-unique/) | | Index name | Specify a name for the index. | [Specify an Index Name](https://www.mongodb.com/docs/manual/core/indexes/create-index/specify-index-name.md#std-label-specify-index-name) | | Create a TTL (Time to Live) index | Delete documents automatically after a specified number of seconds since the indexed field value. | [TTL Indexes](https://www.mongodb.com/docs/manua [source]
Each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) in the replica set or sharded cluster *must* have [featureCompatibilityVersion](https://www.mongodb.com/docs/manual/reference/command/setfeaturecompatibilityversion.md#std-label-set-fcv) set to at least `4.4` to start index builds simultaneously across replica set members. [source]
There are important differences between [commit quorums](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#std-label-createIndexes-cmd-commitQuorum) and [write concerns:](https://www.mongodb.com/docs/manual/reference/write-concern.md#std-label-write-concern) [source]
Replicated build protocol: primary writes a startIndexBuild oplog entry; secondaries build after replicating it and vote by writing to an internal replicated collection on the primary; once the quorum is met and no key-constraint violations remain, the primary writes commitIndexBuild. On a violation the primary aborts and writes abortIndexBuild, and secondaries discard the build job. [source]
setIndexCommitQuorum changes the quorum of an in-progress build. indexNames must list the entire set of in-progress builds from one createIndexes call, and it has no effect on builds started with commitQuorum 0. [source]
Bug SERVER-56976: a build already waiting for votes did not pick up a setIndexCommitQuorum change (found after a half-finished rolling build left one secondary with the index, which treated startIndexBuild as a no-op). Affected 4.4.6 and 5.0.0; fixed in 4.4.7 and 5.0.0-rc0/5.1.0-rc0. On old 4.4.x/5.0.0 binaries lowering the quorum may not unstick a build. [source]
Do not run rolling index builds and replicated (simultaneous) builds concurrently; the docs warn of broken builds and crash loops. [source]
If the options specification had been split into multiple documents like this: `{ unique: true }, { sparse: true, expireAfterSeconds: 3600 }` the index creation operation would have failed. [source]
Apart from planner visibility, a hidden index behaves like an unhidden one: a hidden unique index still enforces its unique constraint, a hidden TTL index still expires documents, and the index still appears in listIndexes and getIndexes() with "hidden": true. [source]
Consider [hiding indexes](https://www.mongodb.com/docs/atlas/performance-advisor/drop-indexes.md#std-label-hidden-indexes) before you drop them. [source]
In the Performance Advisor tab, click Explore Recommendations on the Drop Indexes card. [source]
5. On the index that you want to drop or hide, click Drop Index. [source]
The setIndexCommitQuorum command sets minimum number of data-bearing members that must be prepared to commit their local index builds before the primary node will commit the index. [source]
The minimum number of data-bearing replica set members (i.e. commit quorum), including the primary, that must report a successful index build before the primary marks the indexes as ready. [source]
Issuing setIndexCommitQuorum has no effect on index builds started with commitQuorum of 0. [source]
Index builds use commit quorums. [source]
The commit quorum specifies how many data-bearing voting members, or which voting members, including the primary, must be prepared to commit a simultaneous index build before the primary will execute the commit. [source]
Index builds on a replica set or sharded cluster build simultaneously across all data-bearing replica set members. For sharded clusters, the index build occurs only on shards containing data for the collection being indexed. The primary requires a minimum number of data-bearing voting members (i.e commit quorum), including itself, that must complete the build before marking the index as ready for use. See Index Builds in Replicated Environments for more information. [source]
By default, index builds use "votingMembers" commit quorum, or all data-bearing voting replica set members. The following operation modifies the index build commit quorum to "majority", or a simple majority of data-bearing voting members:. [source]
MongoDB marks index builds in various stages, including waiting on commit quorum, as an idle connection by setting the `active` field to `false`. The `idleConnections: true` setting includes these idle connections in the `$currentOp` output. [source]
If a data-bearing voting node becomes unreachable and the commitQuorum is set to the default votingMembers, index builds can hang until that node comes back online. [source]
commitQuorum specifies how many data-bearing voting members, or which voting members, including the primary, must be prepared to commit the index build before the primary will execute the commit. The default commit quorum is votingMembers, which means all data-bearing members. [source]
If a data-bearing voting node becomes unreachable and the [commitQuorum](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#std-label-createIndexes-cmd-commitQuorum) is set to the default `votingMembers`, index builds can hang until that node comes back online. [source]
The commit quorum specifies how many data-bearing voting members, or which voting members, including the primary, must be prepared to commit a [simultaneous index build](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations-simultaneous-build) before the primary will execute the commit. [source]
By default, index builds use a commit quorum of "votingMembers", or all data-bearing voting members. To start an index build with a non-default commit quorum, specify the commitQuorum parameter to createIndexes or its shell helpers db.collection.createIndex() and db.collection.createIndexes(). [source]
Index builds on a replica set or sharded cluster build simultaneously across all data-bearing replica set members. The primary requires a minimum number of data-bearing voting members (that is, commit quorum), including itself, that must complete the build before marking the index as ready for use. A "voting" member is any replica set member where [`members[n].votes`](https://www.mongodb.com/docs/manual/reference/replica-configuration.md#mongodb-rsconf-rsconf.members-n-.votes) is greater than `0`. See [Index Builds in Replicated Environments](https://www.mongodb.com/docs/manual/core/index-crea [source]
Issuing [`setIndexCommitQuorum`](https://www.mongodb.com/docs/manual/reference/command/setindexcommitquorum.md#mongodb-dbcommand-dbcmd.setIndexCommitQuorum) has no effect on index builds started with [commitQuorum](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#std-label-createIndexes-cmd-commitQuorum) of `0`. [source]
A rolling index build hides and sets priority 0 on one secondary at a time, restarts it as a standalone (no replSetName, different port, disableLogicalSessionCacheRefresh=true), runs createIndex, restarts it as a member, waits for catch-up and unhides it. After all secondaries, rs.stepDown() the primary and repeat on the former primary. [source]
This example creates multiple indexes with the same key pattern and different `sparse` options: [source]
Heavy write load on the target collection reduces write performance and lengthens the build; MongoDB recommends a maintenance window with reduced writes. Unique-index duplicates are only detected at the end of the build, so validate data first or stop non-compliant writers. [source]
Bulk inserts of random data (for example hashed indexes) create random index entries. Once each insert touches a different index entry, the index no longer fits in cache, WiredTiger cache eviction and replacement rate rises, and insert performance drops. [source]
Wildcard text indexes are distinct from [wildcard indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core). Wildcard text indexes support queries that use the [`$text`](https://www.mongodb.com/docs/manual/reference/operator/query/text.md#mongodb-query-op.-text) operator, while wildcard indexes do not. [source]
The wildcard text index supports `$text` queries on all fields in the collection. Consider the following queries: [source]
- [Drop unused, redundant, and hidden indexes](https://www.mongodb.com/docs/atlas/performance-advisor/drop-indexes.md#std-label-pa-drop-index) to improve write performance and free storage space. [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]
- 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]
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]
Hiding an index does not reduce write cost or storage. Hidden indexes are updated on every write and keep consuming disk space and memory, and they still count in db.collection.stats() and $indexStats. [source]
The total uncompressed size in memory of all records in a collection. The [`size`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.size) does not include the size of any indexes associated with the collection, which the [`totalIndexSize`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.totalIndexSize) field reports. [source]
[`storageSize`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.storageSize) does not include index size. See [`totalIndexSize`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.totalIndexSize) for index sizing. [source]
[`totalIndexSize`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.totalIndexSize) includes indexes currently being built in the total size. [source]
[`indexSizes`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.indexSizes) includes the sizes of indexes currently being built. [source]
- The clustered index keys are stored with the collection. The collection size returned by the [`collStats`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-dbcommand-dbcmd.collStats) command includes the clustered index size. [source]
Rolling index builds driven by Atlas, Cloud Manager and Ops Manager (affected MongoDB 4.2.19+, 4.4.13+, 5.0.6+, 6.0.0+; agent 11.13.0.7438-1 to 12.4.0.7702-1) could create indexes with log=(enabled=true), so after a replication rollback or primary crash the indexes were not rolled back with the documents, giving missing or extra entries and wrong query results. Unique indexes were not affected. Remediation: run validate per node, resync bad nodes, upgrade the agent. [source]
Per-index size is available from the indexSizes document in db.collection.stats() (collStats); $indexStats gives per-index usage counters used to find unused indexes before dropping them. [source]
- For each subfield which is itself an object (for example, `account.contact` and `account.access`), the index descends into the object and records its contents. [source]
- For all other subfields, the index records the primitive value into the index. [source]
- If the element is itself an array (as in an embedded array), the index records the *entire* array as a value. [source]
- For non-array, non-object fields, the index records the primitive value into the index. [source]
- Selects another eligible index. [source]
For complete documentation on `wildcardProjection`, see [Options for `wildcard` indexes.](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindex.md#std-label-createIndex-method-wildcard-option) [source]
The wildcard pattern `"$**"` includes all of the fields in the document. However, the `wildcardProjection` field excludes the specified fields from the index. [source]
The index can support queries on any scalar field **except** fields that are excluded by `wildcardProjection`: [source]
- Documents are included in the index if they are missing the wildcard field but have one of the compound fields. [source]
- Index fields, including wildcard fields, can be sorted in ascending (`1`) or descending (`-1`) order. [source]
MongoDB provides [shell helper methods](https://www.mongodb.com/docs/manual/reference/method.md#std-label-js-administrative-methods) for most [database commands](https://www.mongodb.com/docs/manual/reference/command.md#std-label-database-commands). These shell methods offer a simplified syntax and are functionally equivalent to the database commands. [source]
The preceding command removes the `"tenant_customFields"` index from the `salesData` database. [source]
If you frequently query certain document fields, you can specify those fields in a `wildcardProjection` to support those queries without adding unnecessary bloat to the index. [source]
The created index supports queries on any scalar value included in the `wildcardProjection` object. For example, the index supports these queries: [source]
Starting in MongoDB 6.3, 6.0.5, and 5.0.16, the `wildcardProjection` field stores the index projection in its submitted form. Earlier versions of the server may have stored the projection in a normalized form. [source]
The server uses the index the same way, but you may notice a difference in the output of the [`listIndexes`](https://www.mongodb.com/docs/manual/reference/command/listindexes.md#mongodb-dbcommand-dbcmd.listIndexes) and [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getindexes.md#mongodb-method-db.collection.getIndexes) commands. [source]
Atlas shows the type of your new index as Wildcard. [source]
Compass shows the type of your new index as Wildcard. [source]
- [Stable API](https://www.mongodb.com/docs/manual/reference/stable-api.md#std-label-stable-api) V1 does not support `$text` for index creation. [source]
db.collection.hideIndex() and unhideIndex() are mongosh wrappers for the collMod command (index.hidden option). They accept an index name or key document; a text index must be hidden by name. Required privilege is collMod on the database (built-in role dbAdmin). Hiding an already hidden index is a no-op that still writes an empty oplog entry. [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]
```javascript db.restaurants.hideIndex( { borough: 1, ratings: 1 } ); ``` [source]
```javascript db.restaurants.unhideIndex( { borough: 1, city: 1 } ); ``` [source]
```javascript db.movies.hideIndex( { title: 1 } ) [source]
```javascript db.movies.unhideIndex( { title: 1 } ) [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]
- Validate that no documents in the collection violate the index constraints. [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]
From the Indexes tab, hover over the index you want to hide. [source]
2. Click the Hide Index button. [source]
In the dialog box, confirm the index you want to hide. After you confirm your selection, a Hidden badge appears under the Properties column. [source]
You can hide an index to evaluate the impact of dropping an index before you drop it. Unhiding an index also takes less time than rebuilding a dropped index. To hide and unhide an index by using the Atlas UI, see [Manage Atlas Indexes.](https://www.mongodb.com/docs/atlas/atlas-ui/indexes.md#std-label-atlas-ui-indexes) [source]
The Performance Advisor displays a dialog box with a link to the [Atlas UI](https://www.mongodb.com/docs/atlas/atlas-ui/indexes.md#std-label-atlas-ui-indexes) and a copyable [MongoDB Shell](https://www.mongodb.com/docs/mongodb-shell/) command to drop that index. [source]
The dialog box also provides a copyable MongoDB Shell command to hide that index. [source]
6. Drop or hide the index by using the Atlas UI or MongoDB Shell. [source]
For example, the following operation creates a hidden ascending index on the `borough` field: [source]
The index option `hidden` is only returned if the value is `true`. [source]
In the 9.0 manual, hiding an index (hideIndex / collMod) and creating one with createIndex({...},{hidden:true}) both require featureCompatibilityVersion 7.0 or greater. Earlier manual versions listed lower thresholds (4.4 for the original feature), so check the FCV of an older deployment. [source]
During the build, writes to the collection are recorded as keys in a temporary side-writes table that is drained FIFO. A shared S lock (blocks writes) and then a final X lock are held only while the last records drain and the index is committed. Key-generation errors go to a constraint-violation table checked at the end. [source]
You can create a wildcard index on a specific field and its subpaths or on all of the fields in a document. [source]
For details see, Wildcard Indexes. [source]
1 or true to include the field in the wildcard index. [source]
0 or false to exclude the field from the wildcard index. [source]
Wildcard indexes omit the _id field by default. To include the _id field in the wildcard index, you must explicitly include it in the wildcardProjection document: [source]
Starting in MongoDB 7.0, wildcard indexes support ascending (1) and descending (-1) sort order. Earlier versions only supported ascending order. [source]
For complete documentation on Wildcard Indexes, see Wildcard Indexes. [source]
With this wildcard index, MongoDB indexes all scalar values of product_attributes. If the field is a nested document or array, the wildcard index recurses into the document/array and indexes all scalar fields in the document/array. [source]
The path-specific wildcard index syntax is incompatible with the wildcardProjection option. See the parameter documentation for more information. [source]
With this wildcard index, MongoDB indexes all scalar fields for each document in the collection. If a given field is a nested document or array, the wildcard index recurses into the document/array and indexes all scalar fields in the document/array. [source]
Wildcard indexes omit the _id field by default. To include the _id field in the wildcard index, you must explicitly include it in the wildcardProjection document. See parameter documentation for more information. [source]
The following operation creates a wildcard index and uses the wildcardProjection option to include only scalar values of the product_attributes.elements and product_attributes.resistance fields in the index. [source]
While the key pattern "$**" covers all fields in the document, the wildcardProjection field limits the index to only the included fields and their nested fields. [source]
The following operation creates a wildcard index and uses the wildcardProjection document to index all scalar fields for each document in the collection, excluding the product_attributes.elements and product_attributes.resistance fields: [source]
For the database command, see the [`totalIndexSize`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.totalIndexSize) field returned by the [`collStats`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-dbcommand-dbcmd.collStats) command. [source]
The wildcard index continues traversing any additional embedded objects or arrays until it reaches a primitive value. It then indexes the primitive value, along with the full path to that field. [source]
A wildcard index that includes the `account` field descends into the `account` object to traverse and index its contents: [source]
A wildcard index which includes the `ship` field descends into the object to traverse and index its contents: [source]
Wildcard indexes do not record the array position of any given element in an array during indexing. However, MongoDB may still use the wildcard index to fulfill a query that includes a field path with one or more explicit array indices. [source]
db.collection.totalIndexSize [source]
The sum of the [`storageSize`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.storageSize) and [`totalIndexSize`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-data-collStats.totalIndexSize). The `scale` argument affects this value. [source]
The following option is available for [wildcard](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) indexes only: [source]
For complete documentation on Wildcard Indexes, see [Wildcard Indexes.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) [source]
The path-specific wildcard index syntax is incompatible with the `wildcardProjection` option. See the [parameter documentation](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindexes.md#std-label-createIndexes-method-wildcard-option) for more information. [source]
MongoDB supports creating wildcard indexes on a field or a set of fields. A compound index has multiple index terms. A compound wildcard index has one wildcard term and one or more additional index terms. [source]
Wildcard indexes do not replace workload-based index planning. [source]
This example creates a compound wildcard index on the `salesData` collection: [source]
The wildcard, `"customFields.$**"`, specifies all of the sub-fields in the `customFields` field. The other index term, `tenantId`, is not a wildcard specification; it is a standard field specification. [source]
- You can create more than one wildcard index on a collection. [source]
- A wildcard index may cover the same fields as other indexes in the collection. [source]
- Compound wildcard indexes are sparse indexes. [source]
The wildcard index term, `"$**"`, specifies every field in the collection. The `wildcardProjection` limits the index to the specified fields, `"customFields.addr"` and `"customFields.name"`. [source]
The following example creates a partial compound wildcard index on the `tenantId` field and on all the sub-fields in the `customFields` field, only on documents with a `tenantRegion` of `1`. [source]
- Wildcard indexes omit the `_id` field by default. To include the `_id` field in the wildcard index, you must explicitly include it in the `wildcardProjection` document: ```javascript { "wildcardProjection": { "_id": 1, "<field>": 0|1 } } ``` All of the statements in the `wildcardProjection` document must be either inclusion or exclusion statements. You can also include the `_id` field with exclusion statements. This is the only exception to the rule. [source]
This page describes limitations for wildcard indexes such as incompatible properties and unsupported query patterns. [source]
[Compound wildcard indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard/index-wildcard-compound.md#std-label-wildcard-index-compound) have the following restrictions: [source]
- A compound wildcard index can only have one wildcard term. [source]
- The non-wildcard terms in a compound wildcard index must be single key terms. [Multikey](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md#std-label-index-type-multikey) index terms are not permitted. [source]
- Specify a wildcard index as `$**`. [source]
Starting in MongoDB 8.3 (and 8.2.4, 8.0.18, 7.0.29), stricter validation rules apply to `wildcardProjection` in compound wildcard indexes to prevent invalid configurations. [source]
Wildcard indexes **can** support queries where the field equals an empty document `{}`. [source]
In the case that a single wildcard index could support multiple query fields, MongoDB can only use the wildcard index to support one of the query fields. [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]
This is also true for compound wildcard indexes. The wildcard term of a compound index can only support one query predicate, although the non-wildcard terms can support the remaining predicates. [source]
MongoDB may use the same wildcard index to support each independent argument of the query [`$or`](https://www.mongodb.com/docs/manual/reference/operator/query/or.md#mongodb-query-op.-or) or aggregation [`$or`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/or.md#mongodb-expression-exp.-or) operators. [source]
MongoDB can use a wildcard index for satisfying the [`sort()`](https://www.mongodb.com/docs/manual/reference/method/cursor.sort.md#mongodb-method-cursor.sort) **only if** all of the following are true: [source]
- The query planner selects the wildcard index for satisfying the query predicate. [source]
Consider the following wildcard index on the `products` collection: [source]
Assuming that the specified `price` is never an array, MongoDB can use the `product_attributes.$**` wildcard index for satisfying both the [`find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find.md#mongodb-method-db.collection.find) and [`sort()`.](https://www.mongodb.com/docs/manual/reference/method/cursor.sort.md#mongodb-method-cursor.sort) [source]
The following operation creates a wildcard index on the `awards` field: [source]
With this wildcard index, MongoDB indexes all scalar values of `awards`. If the field is a nested document or array, the wildcard index recurses into the document or array and indexes all scalar fields in the document or array. [source]
The wildcard index can support arbitrary single-field queries on `awards` or one of its nested fields: [source]
The following operation creates a wildcard index and uses the `wildcardProjection` option to include only scalar values of the `tomatoes.viewer` and `tomatoes.critic` fields in the index. [source]
This example uses a wildcard index and a `wildcardProjection` document to index the scalar fields for each document in the collection. [source]
The wildcard index excludes the `tomatoes.viewer` and `tomatoes.critic` fields: [source]
Wildcard indexes apply to collections with flexible schemas, where document field names may differ. Use wildcard indexes to support queries against arbitrary or unknown field names. [source]
- Create a wildcard index that only covers specific fields. For example, if you have multiple embedded documents with multiple subfields, you can create an index to cover queries on both embedded documents and their subfields. [source]
In the `wildcardProjection` document, the value `0` or `1` indicates whether the field is included or excluded in the index: [source]
- To use the `wildcardProjection` option, your index key must be `$**`. [source]
If there are document fields that you rarely query, you can create a wildcard index that omits those fields. [source]
The following operation creates a wildcard index on all document fields in the `products` collection, but omits the `attributes.memory` field from the index: [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 [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]
Consider the following wildcard index on a `books` collection: [source]
The index key pattern is `"$**"`. You can create another wildcard index with the same key pattern if you specify a different `wildcardProjection`. For example: [source]
- Before you create an index on an embedded document, consider if you should instead index specific fields in that document, or use a [wildcard index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard.md#std-label-wildcard-index-core) to index all of the document's subfields. [source]
You can create [wildcard indexes](https://www.mongodb.com/docs/manual/core/index-wildcard/) to support queries against unknown or arbitrary fields. To create a wildcard index in Atlas, manually type the wildcard index field (`<field>.$**`) into the Select a field name input. [source]
You can create a wildcard index on `userMetadata` to account for all potential fields within the object. Type the following into the Select a field name input: [source]
Specify a type (`ascending` or `descending`) for your wildcard index, then click Create Index. [source]
MongoDB supports creating indexes on a field, or set of fields, to improve performance for queries. MongoDB supports flexible schemas, meaning document field names may differ within a collection. Use wildcard indexes to support queries against arbitrary or unknown fields. [source]
If your application queries a collection where field names vary between documents, create a wildcard index to support queries on all possible document field names. [source]
If your application repeatedly queries an embedded document field where the subfields are not consistent, create a wildcard index to support queries on all of the subfields. [source]
If your application queries documents that share common characteristics. A compound wildcard index can efficiently cover many queries for documents that have common fields. To learn more, see Compound Wildcard Indexes. [source]
Include or Exclude Fields in a Wildcard Index [source]
The query predicate specifies exactly one field covered by the wildcard index. [source]
If the specified lastName is never an array, MongoDB can use the $** wildcard index to support a covered query. [source]
You can create [wildcard indexes](https://www.mongodb.com/docs/manual/core/index-wildcard/) to support queries against unknown or arbitrary fields. To create a wildcard index in Compass, manually type the wildcard index field (`<field>.$**`) into the Select a field name input. [source]
Wildcard indexes on a single field support queries on any subfield of the indexed field. Use wildcard indexes to support queries on field names that you don't know in advance or vary between documents. [source]
The wildcard index supports single-field queries on `attributes` or its embedded fields. For example, the index supports the following queries: [source]
- Queryable Encryption does not support [TTL Indexes](https://www.mongodb.com/docs/manual/core/index-ttl.md#std-label-index-feature-ttl) or [Unique Indexes.](https://www.mongodb.com/docs/manual/core/index-unique.md#std-label-index-type-unique) [source]
Before you can create the index in this example, you must [drop any existing text indexes](https://www.mongodb.com/docs/manual/core/indexes/drop-index.md#std-label-drop-an-index) on the `blog` collection. [source]
Wildcard indexes can support a [covered query](https://www.mongodb.com/docs/manual/core/query-optimization.md#std-label-covered-queries) only if **all** of the following conditions are true: [source]
You can create a wildcard index that supports queries on all possible document fields. Wildcard indexes support queries on arbitrary or unknown field names. [source]
The following operation creates a wildcard index on all document fields in the `artwork` collection (excluding `_id`): [source]
Compound wildcard indexes were introduced in MongoDB 7.0. They hold one wildcard term plus one or more regular terms, e.g. { tenantId: 1, "customFields.$**": 1 } or { Region: 1, "Attributes.$**": 1 }, and target the attribute pattern so one index serves many dynamic sub-field queries. [source]
A wildcard index supports only one query predicate field per query; other predicates are resolved without it and unsupported ones show in rejectedPlans in explain output. In a compound wildcard index the wildcard term supports one predicate while the regular terms can support the rest. The planner may reuse the same wildcard index for each independent $or argument. [source]
A wildcard index can satisfy a sort only if the planner picks it for the predicate, the sort names only the predicate field, and that field is never an array. A covered query additionally needs exactly one wildcard-covered predicate field and a projection that excludes _id and includes only that field. [source]
No benchmark or measured numbers for wildcard or compound wildcard index performance appeared in any source read; vendor and blog claims of efficiency ("efficiently and easily", "fewer system resources") are unquantified. [source]
If a write modifies an indexed field, MongoDB updates all indexes that have that field as a key, so write-heavy applications can see index maintenance affect performance. [source]
Every insert adds entries to all indexes, every delete removes entries from all indexes, and an update that changes an indexed field removes the old entry and adds a new one in each affected index. [source]
For a bulk load, creating the index after the insert sorts data in memory and performs an ordered insert on all indexes, which the FAQ presents as the remedy for random-insert slowdown. [source]
Indexes in the WiredTiger internal cache use a different representation than on disk but still benefit from index prefix compression, which deduplicates common prefixes and reduces RAM use. Prefix compression is the default for all indexes and can be disabled via storage.wiredTiger.indexConfig.prefixCompression. [source]
Index pages compete with documents for WiredTiger cache. A large unused index leaves less cache for active data, and if eviction threads fall behind, application threads perform eviction themselves and add latency. [source]
Dropping an unused index takes an exclusive collection lock and can stall concurrent writes; run it in a quiet window and watch globalLock.currentQueue and opLatencies.writes before and after. [source]
For an explanation of the output, see [output details.](https://www.mongodb.com/docs/manual/reference/command/collstats.md#std-label-collStats-output) [source]
```javascript db.siteAnalytics.dropIndex( { "url_1" } ) ``` [source]
```javascript db.siteAnalytics.dropIndex( { "url_1_dummyField_1" } ) ``` [source]
1. Click the trash can icon for the index to drop. [source]
From the [Indexes](https://www.mongodb.com/docs/atlas/atlas-ui/indexes.md#std-label-atlas-ui-indexes-tab) tab, to delete an index, click on the trash can icon for that index. A confirmation dialog appears. [source]
2. Confirm the index to delete. [source]
In the dialog, enter the name of the index to delete. [source]
3. Click Drop to drop the index. [source]
An array of in-progress index builds to modify. Each element of the array must be the name of the index. [source]
For more information on the locking behavior of createIndexes, see Index Builds on Populated Collections. [source]
Creating the index in this way allows index builds on one replica set member as a standalone at a time, starting with the secondary members. Creating indexes in this way requires at least one replica set election. To use this resource, the requesting Service Account or API Key must have the Project Data Access Admin role. [source]
1. Open the index creation dialog [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]
Unhiding a hidden index resets its [`$indexStats`.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexstats.md#mongodb-pipeline-pipe.-indexStats) [source]
The following example unhides an existing index. [source]
In the event of a rolling index build cancellation, Atlas generates an [activity feed event](https://www.mongodb.com/docs/atlas/tutorial/activity-feed.md#std-label-view-activity-feed) and sends a notification email to the project owner with the following information: [source]
- Name of the cluster on which the rolling index build failed [source]
- Namespace on which the rolling index build failed [source]
- Name of the cluster on which the index build completed [source]
- Namespace on which the index build completed [source]
Sets the minimum available disk space in megabytes required for index builds. [source]
Increasing the value of `maxNumActiveUserIndexBuilds` allows additional concurrent index builds at the cost of increased pressure on the WiredTiger cache. [source]
The percentage of system memory that MongoDB allocates for index builds during [initial sync](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-initial-sync). The amount of system memory used is bound by the values of [`initialSyncIndexBuildMemoryMinMB`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.initialSyncIndexBuildMemoryMinMB) and [`initialSyncIndexBuildMemoryMaxMB`.](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.initialSyncIndexBuildMemoryMaxMB) [source]
The maximum amount of system memory, in megabytes, that MongoDB can use for index builds during [initial sync.](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-initial-sync) [source]
The minimum amount of system memory, in megabytes, that MongoDB can use for index builds during [initial sync.](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-initial-sync) [source]
Partial indexes only index the documents in a collection that meet a specified filter expression. Partial indexes have lower storage requirements and reduced performance costs for index creation and maintenance. [source]
[Partial indexes](https://www.mongodb.com/docs/manual/core/index-partial.md#std-label-index-type-partial) only index the documents in a collection that meet a specified filter expression. Partial indexes have lower storage requirements and reduced performance costs for index creation and maintenance. [source]
The following table compares the index build behavior starting in MongoDB 7.1 with earlier versions. [source]
The following operation creates an index with a [commit quorum](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindexes.md#std-label-createIndexes-method-commitQuorum) of `"majority"`: [source]
Rolling index builds lower the resiliency of your cluster and increase build duration. [source]
The following procedure to build indexes in a rolling fashion applies to sharded clusters deployments, and not replica set deployments. For the procedure for replica sets, see [Create a Rolling Index Build on Replica Sets](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets.md) instead. [source]
For more information on the locking behavior of [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.createIndexes), see [Index Builds on Populated Collections.](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations) [source]
- To change the `hidden` option for an index to `true`, use the [`db.collection.hideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.hideindex.md#mongodb-method-db.collection.hideIndex) method: [source]
- To change the `hidden` option for an index to `false`, use the [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideindex.md#mongodb-method-db.collection.unhideIndex) method: [source]
Improved disk space management for index builds. An index build may be automatically stopped if the available disk space is below the minimum specified in the indexBuildMinAvailableDiskSpaceMB parameter. If a member has already voted to commit the index, then the index build is not stopped. [source]
Previous versions of MongoDB supported building indexes either in the foreground or background. Foreground index builds were fast and produced more efficient index data structures, but required blocking all read-write access to the parent database of the collection being indexed for the duration of the build. Background index builds were slower and produced less efficient results, but allowed read-write access to the database and its collections during the build. [source]
MongoDB ignores the background index build option if specified to createIndexes or its shell helpers createIndex() and createIndexes(). [source]
Constraint Violations During Index Build [source]
Similarly, an application can successfully write documents to the inventory collection with duplicate values of product_sku while the index build is in progress. [source]
By default, the server allows up to three concurrent index builds. To change the number of allowed concurrent index builds, modify the maxNumActiveUserIndexBuilds parameter. [source]
Index Build Impact on Database Performance [source]
Index Builds During Write-Heavy Workloads [source]
Consider designating a maintenance window during which applications stop or reduce write operations against the collection. Start the index build during this maintenance window. [source]
The primary receives the createIndexes command and immediately creates a "startIndexBuild" oplog entry associated with the index build. [source]
The secondaries start the index build after they replicate the "startIndexBuild" oplog entry. [source]
If there are no key constraint violations, the primary completes the index build, marks the index as ready for use, and creates an associated "commitIndexBuild" oplog entry. [source]
The secondaries replicate the "commitIndexBuild" oplog entry and complete the index build. [source]
If the secondaries instead replicate an "abortIndexBuild" oplog entry, they abort the index build and discard the build job. [source]
For sharded clusters, the index build occurs only on shards containing data for the collection being indexed. [source]
Rolling index builds take at most one replica set member at a time, starting with the secondary members, and build the index on that member as a standalone. Rolling index builds require at least one replica set election. Use rolling index builds only if you meet the requirements listed on the rolling index pages, as the procedure lowers the resiliency of the cluster. [source]
Interrupted Index Builds on Atlas Infinite [source]
Interrupted Index Builds on Primary and Secondary mongod [source]
Interrupted Index Builds on Standalone mongod [source]
If the mongod shuts down during the index build, the index build job and all progress is lost. Restarting the mongod does not restart the index build. You must re-issue the createIndex() operation to restart the index build. [source]
MongoDB can pause an in-progress index build to perform a rollback. [source]
If the rollback does not revert the index build, MongoDB restarts the index build after completing the rollback. [source]
If the rollback reverts the index build, you must re-create the index or indexes after the rollback completes. [source]
Observe Stopped and Resumed Index Builds in the Logs [source]
While an index is being built, progress is written to the MongoDB log. If an index build is stopped and resumed there will be log messages with fields like these: [source]
"msg":"Index build: wrote resumable state to disk", [source]
Do not use killOp to terminate an in-progress index builds in replica sets or sharded clusters. [source]
If the mongod replicates an "abortIndexBuild" oplog entry, it aborts the index build and discards the build job. [source]
For details, see Hidden Indexes. [source]
db.collection.hideIndex(<index>) [source]
Hiding an already hidden index has no effect on the index. However, the operation will still generate an empty oplog entry. [source]
- Perform [rolling index builds](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets/#rolling-index-builds-on-replica-sets) to reduce the performance impact of building indexes on [replica sets](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-replica-set) and [sharded clusters.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-sharded-cluster) [source]
If after the evaluation, the user decides to drop the index, you can drop the hidden index; i.e. you do not need to unhide it first to drop it. [source]
For more information on hidden indexes, see [Hidden Indexes.](https://www.mongodb.com/docs/manual/core/index-hidden.md) [source]
Provides metrics on [index builds](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations) after the server last started. [source]
Total number of index builds. [source]
Provides metrics for index bulk builder operations. Use these metrics to diagnose index build issues with [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.createIndexes), collection cloning during initial sync, index builds that resume after startup, and statistics on disk usage by the external sorter. [source]
The number of times the bulk builder was created for a resumable index build. [source]
If `true` and [`deprioritizationGate`](https://www.mongodb.com/docs/manual/reference/command/serverstatus.md#mongodb-serverstatus-serverstatus.queues.execution.deprioritizationGate) is `true`, background tasks such as index builds and TTL deletions initiate as low priority. [source]
Defines the maximum size of the internal cache that WiredTiger uses for all data. The memory consumed by an index build (see [`maxIndexBuildMemoryUsageMegabytes`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.maxIndexBuildMemoryUsageMegabytes)) is separate from the WiredTiger cache memory. [source]
Defines the maximum amount of memory to allocate for cache as a percentage of physical RAM. The memory that an index build consumes (see [`maxIndexBuildMemoryUsageMegabytes`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.maxIndexBuildMemoryUsageMegabytes)) is separate from the WiredTiger cache memory. [source]
**Tip: Hide an Index Before Dropping It** [source]
- Issue an index build [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindex.md#mongodb-method-db.collection.createIndex) from a [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instance. The operation only builds the collection's index on the shard(s) missing the index. [source]
- Perform a [rolling index build](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-sharded-clusters.md) for the collection on the affected shard(s). [source]
- Perform a [rolling index build](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-sharded-clusters.md) for the collection on the affected shard. [source]
1. The primary receives the [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createindexes.md#mongodb-dbcommand-dbcmd.createIndexes) command and immediately creates a "startIndexBuild" oplog entry associated with the index build. [source]
MongoDB can pause an in-progress index build to perform a [rollback.](https://www.mongodb.com/docs/manual/core/replica-set-rollbacks.md#std-label-replica-set-rollbacks) [source]
Do *not* use [`killOp`](https://www.mongodb.com/docs/manual/reference/command/killop.md#mongodb-dbcommand-dbcmd.killOp) to terminate an in-progress index builds in replica sets or sharded clusters. [source]
Returns an array that holds a list of documents that identify and describe the existing indexes on the collection, including [hidden indexes](https://www.mongodb.com/docs/manual/core/index-hidden.md#std-label-index-type-hidden) and indexes that are currently being built. [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]
By default, you can have up to three concurrent index builds. To learn more, see [Maximum Concurrent Index Builds.](https://www.mongodb.com/docs/manual/core/index-creation/#maximum-concurrent-index-builds) [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]
The Performance Advisor suggests dropping unused, redundant, and hidden indexes to improve write performance and increase storage space. [source]
Atlas doesn't use hidden indexes to support queries. They still impact write performance and consume storage space. To learn more, see [Hidden Indexes.](https://www.mongodb.com/docs/manual/core/index-hidden/) [source]
The Performance Advisor always recommends dropping hidden indexes. If you determine that a hidden index is unnecessary, drop it. [source]
The Atlas Performance Advisor page displays hidden indexes from your top 20 most active namespaces at the time you load the page. If you have more than 20 namespaces, the Performance Advisor page might not display all of your namespaces with hidden indexes. [source]
Only use a [rolling index build](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md#std-label-rolling-index-build) if your deployment matches one of the following cases: [source]
If your deployment does not meet this criteria, use the [default index build.](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-operations) [source]
With Atlas, you can temporarily [scale](https://www.mongodb.com/docs/atlas/scale-cluster/) your cluster to meet the requirements for a traditional index build. However, Atlas charges to scale your cluster. See [Cluster Configuration Costs](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs/) for more information. [source]
If you change the weights in your index after it is created, MongoDB needs to reindex the collection. Reindexing can negatively impact performance, especially on large collections. For more information, see [Index Builds on Populated Collections.](https://www.mongodb.com/docs/manual/core/index-creation.md#std-label-index-creation-background) [source]
Active Indexing Operations do not apply to [rolling index builds.](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md#std-label-rolling-index-build) [source]
- Hidden indexes are included in [`listIndexes`](https://www.mongodb.com/docs/manual/reference/command/listindexes.md#mongodb-dbcommand-dbcmd.listIndexes) and [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getindexes.md#mongodb-method-db.collection.getIndexes) results. [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]
- the index key specification document to the [`db.collection.hideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.hideindex.md#mongodb-method-db.collection.hideIndex) method: [source]
- the index key specification document to the [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideindex.md#mongodb-method-db.collection.unhideIndex) method: [source]
By default, WiredTiger uses Snappy block compression for all collections and prefix compression for all indexes. Compression defaults are configurable at a global level and can also be set on a per-collection and per-index basis during collection and index creation. [source]
Hidden indexes are included in listIndexes and db.collection.getIndexes() results. [source]
Hiding an unhidden index or unhiding a hidden index resets its $indexStats. Hiding an already hidden index or unhiding an already unhidden index does not reset the $indexStats. [source]
db.restaurants.unhideIndex( "borough_1_ratings_1" ); // Specify the index name [source]
Hiding an unhidden index, or unhiding a hidden one, resets that index's $indexStats counters. Hiding an already hidden index (or unhiding an unhidden one) does not reset them. Usage counts gathered before the toggle are lost, so record them first. [source]
Workflow shown by Percona: run explain() to see which index wins, hideIndex(), re-run explain() to confirm the planner picks another plan (the hidden index is absent from rejected plans too), then unhideIndex() if the plan regresses. [source]
Never run rolling and replicated (default) index builds concurrently; MongoDB warns of broken builds and crash loops. [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 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]
- Atlas always creates indexes for entire clusters. If you create an index while viewing the Performance Advisor for a single shard in a sharded cluster, Atlas creates that index for the entire sharded cluster. [source]
The following example changes the `expireAfterSeconds` value for an index with the pattern `{ "lastModifiedDate": 1 }` on the `tickets` collection: [source]
- Deleting many documents can fragment storage files, additionally impacting performance. You may need to run the [compact](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-compact) command on your collection or perform a [Initial Sync](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-initial-sync) to reclaim space and optimize storage. [source]
```javascript { unique: true, name: "myUniqueIndex" } ``` [source]
```javascript [ { v: 2, key: { _id: 1 }, name: '_id_' }, { v: 2, key: { url: 1 }, name: 'url_1', unique: true } ] ``` [source]
You can also enforce a unique constraint on the combination of index key values for a [compound index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound.md#std-label-index-type-compound) [source]
For a ranged sharded collection, only the following indexes can be [unique:](https://www.mongodb.com/docs/manual/core/index-unique.md#std-label-index-type-unique) [source]
- The default `_id` index; however, the `_id` index only enforces the uniqueness constraint **per shard** if the `_id` field is not the shard key. [source]
Starting in MongoDB 5.0, [unique sparse](https://www.mongodb.com/docs/manual/core/index-sparse.md#std-label-sparse-unique-index) and [unique non-sparse](https://www.mongodb.com/docs/manual/core/indexes/index-properties.md#std-label-unique-index) indexes with the same [key pattern](https://www.mongodb.com/docs/manual/reference/method/db.collection.createindexes.md#std-label-key_patterns) can exist on a single collection. [source]
In order for other [`findAndModify`](https://www.mongodb.com/docs/manual/reference/command/findandmodify.md#mongodb-dbcommand-dbcmd.findAndModify) operations to update the newly-inserted document, **all** of the following conditions must be met: [source]
- Exactly one [`findOneAndUpdate()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.findoneandupdate.md#mongodb-method-db.collection.findOneAndUpdate) operation will successfully insert a new document. [source]
In order for other [`findOneAndUpdate()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.findoneandupdate.md#mongodb-method-db.collection.findOneAndUpdate) operations to update the newly-inserted document, **all** of the following conditions must be met: [source]
After you create the index, you can shard the `orders` collection: [source]
After you create the index, you can shard the `customers` collection: [source]
For example, the following operation creates an index on the `log_events` collection's `createdAt` field and specifies the `expireAfterSeconds` value of `10` to set the expiration time to be ten seconds after the time specified by `createdAt`. [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]
- **Remove partial build progress**: Atlas preserves the index definition but removes partial build progress so the build can restart from scratch. [source]
All of the statements in the wildcardProjection document must be either inclusion or exclusion statements. You can also include the _id field with exclusion statements. This is the only exception to the rule. [source]
key: { "product_attributes.$**" : 1 }, [source]
- Optimize queries by implementing filtering, reducing leading wildcards and heavily nested clauses, and retrieving only necessary data. [source]
A document that reports data from the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredTiger) storage engine for each index in the collection. Other storage engines will return an empty document. [source]
You can use a `wildcardProjection` to specify individual sub-fields. [source]
Returns statistics regarding the use of each index for the collection. If running with [access control](https://www.mongodb.com/docs/manual/core/authorization.md#std-label-authorization), authenticate as a user with at least the [`clusterMonitor`](https://www.mongodb.com/docs/manual/reference/built-in-roles.md#mongodb-authrole-clusterMonitor) role. [source]
```json
 { "wildcardProjection" : { "attributes" : 0, "users" : 1 } } ``` [source]
```json
 { "wildcardProjection" : { "attributes" : 0, "_id" : 1 } } ``` [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]
3. Calculate index storage, total disk storage, and memory. [source]
```none index storage = 1.2 * (67 * T_Total + 640) ``` [source]
```none total disk storage = N * (index storage + sum of the document storage per field) ``` [source]
db.collection.createIndex( { "$**": <sortOrder> } ) [source]
db.employees.createIndex( { "$**" : 1 } ) [source]
Returns statistics regarding the use of each index for the collection. If running with access control, authenticate as a user with at least the clusterMonitor role. [source]
Each member "votes" to commit the build once it finishes indexing data in the collection. [source]
On Atlas Infinite clusters, an interrupted createIndexes operation always resumes. [source]
The Atlas UI doesn't support building indexes with a rolling build for Free clusters and Flex clusters. [source]
setIndexCommitQuorum: <string>, [source]
commitQuorum: <int> | <string>, [source]
"votingMembers" - all data-bearing voting replica set members (Default). A "voting" member is any replica set member where members[n].votes is greater than 0. [source]
Commit Quorum Contrasted with Write Concern [source]
"setIndexCommitQuorum" : "invoices", [source]
"commitQuorum" : "majority" [source]
commitQuorum: 'votingMembers', [source]
The [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideindex.md#mongodb-method-db.collection.unhideIndex) method takes the following parameter: [source]
The [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideindex.md#mongodb-method-db.collection.unhideIndex) is a [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) shell wrapper for the [`collMod`](https://www.mongodb.com/docs/manual/reference/command/collmod.md#mongodb-dbcommand-dbcmd.collMod) command. [source]
While waiting for commit quorum, the mongod adds any additional keys generated from write operations to the collection being indexed to the side writes table and periodically drains the table. [source]
db.collection.hideIndex() (mongosh method) [source]
The db.collection.hideIndex() is a mongosh shell wrapper for the collMod command. [source]

Related concepts

index — is a hypernym of MongoDB wildcard and hidden indexes, index builds and index overhead
index build — is a part of MongoDB wildcard and hidden indexes, index builds and index overhead
hidden index — is a hyponym of MongoDB wildcard and hidden indexes, index builds and index overhead
commit quorum — is a part of MongoDB wildcard and hidden indexes, index builds and index overhead
unique index — is a hyponym of MongoDB wildcard and hidden indexes, index builds and index overhead
index overhead — is a problem of MongoDB wildcard and hidden indexes, index builds and index overhead
dropIndex — is a related of MongoDB wildcard and hidden indexes, index builds and index overhead
collStats — is a measure of MongoDB wildcard and hidden indexes, index builds and index overhead
TTL index — is a hyponym of MongoDB wildcard and hidden indexes, index builds and index overhead
text index — is a hyponym of MongoDB wildcard and hidden indexes, index builds and index overhead
hashed index — is a hyponym of MongoDB wildcard and hidden indexes, index builds and index overhead

Children

Attribute pattern and wildcardProjection design
Cosmos DB for MongoDB wildcard differences (frontier, viability 2.15 / 5, below research gate)
Index build resource limits (maxNumActiveUserIndexBuilds, disk space)
Random-key (hashed/UUID) index insert behavior
Resumable index builds
Rolling index builds
Unused index detection with $indexStats
Wildcard index query-planner behavior and explain rejectedPlans
WiredTiger cache eviction and dirty ratio
dropIndexes abort semantics

Frontier under this node: Cosmos DB for MongoDB wildcard differences (2.15)

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