createIndexes
On this page
Definition
createIndexes
Builds one or more indexes on a collection.
Tip
In the
mongo
Shell, this command can also be run through thedb.collection.createIndex()
anddb.collection.createIndexes()
helper methods..Helper methods are convenient for
mongo
users, but they may not return the same level of information as database commands. In cases where the convenience is not needed or the additional return fields are required, use the database command.The
createIndexes
command takes the following form:db.runCommand( { createIndexes: <collection>, indexes: [ { key: { <key-value_pair>, <key-value_pair>, ... }, name: <index_name>, <option1>, <option2>, ... }, { ... }, { ... } ], writeConcern: { <write concern> }, commitQuorum: <int|string>, comment: <any> } ) The
createIndexes
command takes the following fields:FieldTypeDescriptioncreateIndexes
stringThe collection for which to create indexes.indexes
arraySpecifies the indexes to create. Each document in the array specifies a separate index.writeConcern
documentOptional. A document expressing the write concern. Omit to use the default write concern.
New in version 3.4.
integer or stringOptional. The minimum number of data-bearing voting 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. A "voting" member is any replica set member wheremembers[n].votes
is greater than0
.Supports the following values:
"votingMembers"
- all data-bearing voting replica set members (Default)."majority"
- a simple majority of data-bearing voting replica set members.<int>
- a specific number of data-bearing voting replica set members.0
- Disables quorum-voting behavior. Members start the index build simultaneously but do not vote or wait for quorum before completing the index build. If you start an index build with a commit quorum of0
, you cannot later modify the commit quorum usingsetIndexCommitQuorum
.A replica set tag name.
New in version 4.4.
comment
anyOptional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:
mongod log messages, in the
attr.command.cursor.comment
field.Database profiler output, in the
command.comment
field.currentOp
output, in thecommand.comment
field.
A comment can be any valid BSON type (string, integer, object, array, etc).
New in version 4.4.
Each document in the
indexes
array can take the following fields:FieldTypeDescriptionkey
documentSpecifies the index's fields. For each field, specify a key-value pair in which the key is the name of the field to index and the value is either the index direction or index type. If specifying direction, specify
1
for ascending or-1
for descending.MongoDB supports several different index types including text, geospatial, and hashed indexes. See index types for more information.
Changed in version 4.2: MongoDB 4.2 wildcard indexes support workloads where users query against custom fields or a large variety of fields in a collection:
To create a wildcard index on all fields and subfields in a document, specify
{ "$**" : 1 }
as the index key. You cannot specify a descending index key when creating a wildcard index.You can also either include or exclude specific fields and their subfields from the index using the optional
wildcardProjection
parameter.Wildcard indexes omit the
_id
field by default. To include the_id
field in the wildcard index, you must explicitly include it in thewildcardProjection
document:{ "wildcardProjection" : { "_id" : 1, "<field>" : 0|1 } } With the exception of explicitly including
_id
field, you cannot combine inclusion and exclusion statements in thewildcardProjection
document.You can create a wildcard index on a specific field and its subpaths by specifying the full path to that field as the index key and append
"$**"
to the path:{ "path.to.field.$**" : 1 }
You cannot specify a descending index key when creating a wildcard index.
The path-specific wildcard index syntax is incompatible with the
wildcardProjection
option. You cannot specify additional inclusions or exclusions on the specified path.
The wildcard index key must use one of the syntaxes listed above. For example, you cannot specify a compound index key. For more complete documentation on wildcard indexes, including restrictions on their creation, see Wildcard Index Restrictions.
The
mongod
featureCompatibilityVersion must be4.2
to create wildcard indexes. For instructions on setting the fCV, see Set Feature Compatibility Version on MongoDB 4.4 Deployments.For examples of wildcard index creation, see Create a Wildcard Index.
name
stringA name that uniquely identifies the index.background
booleanOptional. Deprecated in MongoDB 4.2.
For feature compatibility version (fcv)
"4.0"
, specifyingbackground: true
directs MongoDB to build the index in the background. Background builds do not block operations on the collection. The default value isfalse
.Changed in version 4.2.
For feature compatibility version (fcv)
"4.2"
, all index builds use an optimized build process that holds the exclusive lock only at the beginning and end of the build process. The rest of the build process yields to interleaving read and write operations. MongoDB ignores thebackground
option if specified.
unique
booleanOptional. 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 isfalse
.The option is unavailable for hashed indexes.
partialFilterExpression
documentOptional. If specified, the index only references documents that match the filter expression. See Partial Indexes for more information.
A filter expression can include:
equality expressions (i.e.
field: value
or using the$eq
operator),$exists: true
expression,$type
expressions,$and
operator at the top-level only
You can specify a
partialFilterExpression
option for all MongoDB index types.sparse
booleanOptional. If
true
, the index only references documents with the specified field. These indexes use less space but behave differently in some situations (particularly sorts). The default value isfalse
. See Sparse Indexes for more information.The following index types are sparse by default and ignore this option:
For a compound index that includes
2dsphere
index key(s) along with keys of other types, only the2dsphere
index fields determine whether the index references a document.MongoDB provides the option to create partial indexes. These offer a superset of the functionality of sparse indexes and are preferred instead.
expireAfterSeconds
integerOptional. Specifies a value, in seconds, as a TTL to control how long MongoDB retains documents in this collection. See Expire Data from Collections by Setting TTL for more information on this functionality. This applies only to TTL indexes.booleanOptional. 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.
Default is
false
.To use the
hidden
option, you must have featureCompatibilityVersion set to4.4
or greater. However, once hidden, the index remains hidden even with featureCompatibilityVersion set to4.2
on MongoDB 4.4 binaries.New in version 4.4.
storageEngine
documentOptional. Allows users to configure the storage engine on a per-index basis when creating an index.
The
storageEngine
option should take the following form:storageEngine: { <storage-engine-name>: <options> } 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.
weights
documentOptional. For text indexes, a document that contains field and weight pairs. The weight is an integer ranging from 1 to 99,999 and denotes the significance of the field relative to the other indexed fields in terms of the score. You can specify weights for some or all the indexed fields. See Control Search Results with Weights to adjust the scores. The default value is1
.default_language
stringOptional. For text indexes, the language that determines the list of stop words and the rules for the stemmer and tokenizer. See Text Search Languages for the available languages and Specify a Language for Text Index for more information and examples. The default value isenglish
.language_override
stringOptional. For text indexes, the name of the field, in the collection's documents, that contains the override language for the document. The default value islanguage
. See Use any Field to Specify the Language for a Document for an example.textIndexVersion
integerOptional. The
text
index version number. Users can use this option to override the default version number.For available versions, see Versions.
2dsphereIndexVersion
integerOptional. The
2dsphere
index version number. Users can use this option to override the default version number.For the available versions, see Versions.
bits
integermin
numberOptional. For 2d indexes, the lower inclusive boundary for the longitude and latitude values. The default value is-180.0
.max
numberOptional. For 2d indexes, the upper inclusive boundary for the longitude and latitude values. The default value is180.0
.bucketSize
numberFor geoHaystack indexes, specify the number of units within which to group the location values; i.e. group in the same bucket those location values that are within the specified number of units to each other.
The value must be greater than 0.
collation
documentOptional. Specifies the collation for the index.
Collation allows users to specify language-specific rules for string comparison, such as rules for lettercase and accent marks.
If you have specified a collation at the collection level, then:
If you do not specify a collation when creating the index, MongoDB creates the index with the collection's default collation.
If you do specify a collation when creating the index, MongoDB creates the index with the specified collation.
The collation option has the following syntax:
collation: { locale: <string>, caseLevel: <boolean>, caseFirst: <string>, strength: <int>, numericOrdering: <boolean>, alternate: <string>, maxVariable: <string>, backwards: <boolean> } When specifying collation, the
locale
field is mandatory; all other collation fields are optional. For descriptions of the fields, see Collation Document.New in version 3.4.
wildcardProjection
documentOptional.
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 }
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
ortrue
to include the field in the wildcard index.0
orfalse
to exclude the field from the wildcard index.
Wildcard indexes omit the
_id
field by default. To include the_id
field in the wildcard index, you must explicitly include it in thewildcardProjection
document:{ "wildcardProjection" : { "_id" : 1, "<field>" : 0|1 } } With the exception of explicitly including
_id
field, you cannot combine inclusion and exclusion statements in thewildcardProjection
document.The
mongo
shell provides the methodsdb.collection.createIndex()
anddb.collection.createIndexes()
as wrappers for thecreateIndexes
command.
Considerations
MongoDB disallows the creation of version 0 indexes. To upgrade existing version 0 indexes, see Version 0 Indexes.
Index Names
Note
Changed in MongoDB 4.2
Starting in version 4.2, for featureCompatibilityVersion set to "4.2"
or greater, MongoDB removes the
Index Name Length limit of 127 byte maximum. In previous
versions or MongoDB versions with
featureCompatibilityVersion (fCV) set to
"4.0"
, index names must fall within the
limit.
Starting in version 4.2, the createIndexes
command and
the mongo
shell helpers
db.collection.createIndex()
and
db.collection.createIndexes()
report an error if you
create an index with one name, and then try to create the same index
again but with another name.
{ "ok" : 0, "errmsg" : "Index with name: x_1 already exists with a different name", "code" : 85, "codeName" : "IndexOptionsConflict" }
In previous versions, MongoDB did not create the index again, but
would return a response object with ok
value of 1
and a note
that implied that the index was not recreated. For example:
{ "numIndexesBefore" : 2, "numIndexesAfter" : 2, "note" : "all indexes already exist", "ok" : 1 }
Replica Sets and Sharded Clusters
Note
Requires featureCompatibilityVersion 4.4+
Each mongod
in the replica set or sharded cluster
must have featureCompatibilityVersion set to at
least 4.4
to start index builds simultaneously across
replica set members.
MongoDB 4.4 running featureCompatibilityVersion: "4.2"
builds
indexes on the primary before replicating the index build to
secondaries.
Starting with MongoDB 4.4, 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.
To start an index build with a non-default commit quorum, specify the commitQuorum.
MongoDB 4.4 adds the setIndexCommitQuorum
command for
modifying the commit quorum of an in-progress index build.
In MongoDB 4.2 and earlier, index builds on a replica set or sharded cluster build on the primary first before replicating to the secondaries. See Index Builds In Replicated Environments (4.2) for the MongoDB 4.2 index build behavior.
To minimize the impact of building an index on replica sets and sharded clusters, use a rolling index build procedure as described on Rolling Index Builds on Replica Sets.
Collation and Index Types
The following indexes only support simple binary comparison and do not support collation:
text indexes,
2d indexes, and
geoHaystack indexes.
Tip
To create a text
, a 2d
, or a geoHaystack
index on a
collection that has a non-simple collation, you must explicitly
specify {collation: {locale: "simple"} }
when creating the
index.
Behavior
Concurrency
Changed in version 4.2.
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.
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.
For more information on the locking behavior of createIndexes
, see
Index Builds on Populated Collections.
Memory Usage Limit
createIndexes
supports building one or more indexes on a
collection. createIndexes
uses a combination of memory and
temporary files on disk to complete index builds. The default limit on
memory usage for createIndexes
is 200 megabytes (for
versions 4.2.3 and later) and 500 (for versions 4.2.2 and earlier),
shared between all indexes built using a single
createIndexes
command. Once the memory limit is reached,
createIndexes
uses temporary disk files in a subdirectory
named _tmp
within the --dbpath
directory to complete the build.
You can override the memory limit by setting the
maxIndexBuildMemoryUsageMegabytes
server parameter.
Setting a higher memory limit may result in faster completion of index
builds. However, setting this limit too high relative to the unused RAM
on your system can result in memory exhaustion and server shutdown.
Index Options
Non-Collation and Non-Hidden Options
With the exception of the collation option, if you create an index with one set of index options and then try to recreate the same index but with different index options, MongoDB will not change the options nor recreate the index.
The hidden option can be changed without dropping and recreating the index. See Hidden Option.
To change the other index options, drop the existing index with
db.collection.dropIndex()
before running
createIndexes
with the new options.
Collation Option
New in version 3.4.
Unlike other index options, you can create multiple indexes on the same key(s) with different collations. To create indexes with the same key pattern but different collations, you must supply unique index names.
If you have specified a collation at the collection level, then:
If you do not specify a collation when creating the index, MongoDB creates the index with the collection's default collation.
If you do specify a collation when creating the index, MongoDB creates the index with the specified collation.
Tip
By specifying a collation strength
of 1
or 2
, you can
create a case-insensitive index. Index with a collation strength
of 1
is both diacritic- and case-insensitive.
To use an index for string comparisons, an operation must also specify the same collation. That is, an index with a collation cannot support an operation that performs string comparisons on the indexed fields if the operation specifies a different collation.
Warning
Because indexes that are configured with collation use ICU collation keys to achieve sort order, collation-aware index keys may be larger than index keys for indexes without collation.
For example, the collection myColl
has an index on a string
field category
with the collation locale "fr"
.
db.myColl.createIndex( { category: 1 }, { collation: { locale: "fr" } } )
The following query operation, which specifies the same collation as the index, can use the index:
db.myColl.find( { category: "cafe" } ).collation( { locale: "fr" } )
However, the following query operation, which by default uses the "simple" binary collator, cannot use the index:
db.myColl.find( { category: "cafe" } )
For a compound index where the index prefix keys are not strings, arrays, and embedded documents, an operation that specifies a different collation can still use the index to support comparisons on the index prefix keys.
For example, the collection myColl
has a compound index on the
numeric fields score
and price
and the string field
category
; the index is created with the collation locale
"fr"
for string comparisons:
db.myColl.createIndex( { score: 1, price: 1, category: 1 }, { collation: { locale: "fr" } } )
The following operations, which use "simple"
binary collation
for string comparisons, can use the index:
db.myColl.find( { score: 5 } ).sort( { price: 1 } ) db.myColl.find( { score: 5, price: { $gt: NumberDecimal( "10" ) } } ).sort( { price: 1 } )
The following operation, which uses "simple"
binary collation
for string comparisons on the indexed category
field, can use
the index to fulfill only the score: 5
portion of the query:
db.myColl.find( { score: 5, category: "cafe" } )
Important
Matches against document keys, including embedded document keys, use simple binary comparison. This means that a query for a key like "foo.bár" will not match the key "foo.bar", regardless of the value you set for the strength parameter.
Hidden Option
New in version 4.4.
Note
To hide an index, you must have featureCompatibilityVersion set to 4.4
or greater. However, once hidden, the
index remains hidden even with featureCompatibilityVersion set to 4.2
on MongoDB 4.4 binaries.
To change the hidden
option for existing indexes, you can use the
following mongo
shell methods:
For example,
To change the
hidden
option for an index totrue
, use thedb.collection.hideIndex()
method:db.restaurants.hideIndex( { borough: 1, ratings: 1 } ); To change the
hidden
option for an index tofalse
, use thedb.collection.unhideIndex()
method:db.restaurants.unhideIndex( { borough: 1, city: 1 } );
Wildcard Indexes
New in version 4.2.
Wildcard indexes omit the
_id
field by default. To include the_id
field in the wildcard index, you must explicitly include it in thewildcardProjection
document:{ "wildcardProjection" : { "_id" : 1, "<field>" : 0|1 } } With the exception of explicitly including
_id
field, you cannot combine inclusion and exclusion statements in thewildcardProjection
document.The
mongod
featureCompatibilityVersion must be4.2
to create wildcard indexes. For instructions on setting the fCV, see Set Feature Compatibility Version on MongoDB 4.4 Deployments.Wildcard indexes do not support the following index types or properties:
Note
Wildcard Indexes are distinct from and incompatible with Wildcard Text Indexes. Wildcard indexes cannot support queries using the
$text
operator.For complete documentation on wildcard index restrictions, see Wildcard Index Restrictions.
For examples of wildcard index creation, see Create a Wildcard Index. For complete documentation on Wildcard Indexes, see Wildcard Indexes.
Transactions
Changed in version 4.4.
You can create collections and indexes inside a distributed transaction if the transaction is not a cross-shard write transaction.
To use createIndexes
in a transaction, the transaction must use read
concern "local"
. If you specify a read concern level
other than "local"
, the transaction fails.
Example
The following command builds two indexes on the inventory
collection of
the products
database:
db.getSiblingDB("products").runCommand( { createIndexes: "inventory", indexes: [ { key: { item: 1, manufacturer: 1, model: 1 }, name: "item_manufacturer_model", unique: true }, { key: { item: 1, supplier: 1, model: 1 }, name: "item_supplier_model", unique: true } ], writeConcern: { w: "majority" } } )
When the indexes successfully finish building, MongoDB returns a results
document that includes a status of "ok" : 1
.
Create a Wildcard Index
New in version 4.2: The mongod
featureCompatibilityVersion must be 4.2
to
create wildcard indexes. For instructions on setting the fCV, see
Set Feature Compatibility Version on MongoDB 4.4 Deployments.
For complete documentation on Wildcard Indexes, see Wildcard Indexes.
The following lists examples of wildcard index creation:
Create a Wildcard Index on a Single Field Path
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:
{ "_id" : ObjectId("5c1d358bf383fbee028aea0b"), "product_name" : "Blaster Gauntlet", "product_attributes" : { "price" : { "cost" : 299.99 "currency" : USD } ... } }, { "_id" : ObjectId("5c1d358bf383fbee028aea0c"), "product_name" : "Super Suit", "product_attributes" : { "superFlight" : true, "resistance" : [ "Bludgeoning", "Piercing", "Slashing" ] ... }, }
The following operation creates a wildcard index on the
product_attributes
field:
use inventory db.runCommand( { createIndexes: "products_catalog", indexes: [ { key: { "product_attributes.$**" : 1 }, name: "wildcardIndex" } ] } )
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.
The wildcard index can support arbitrary single-field queries on
product_attributes
or one of its nested fields:
db.products_catalog.find( { "product_attributes.superFlight" : true } ) db.products_catalog.find( { "product_attributes.maxSpeed" : { $gt : 20 } } ) db.products_catalog.find( { "product_attributes.elements" : { $eq: "water" } } )
Note
The path-specific wildcard index syntax is incompatible with the
wildcardProjection
option. See the parameter documentation for more
information.
Create a Wildcard Index on All Field Paths
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:
{ "_id" : ObjectId("5c1d358bf383fbee028aea0b"), "product_name" : "Blaster Gauntlet", "product_attributes" : { "price" : { "cost" : 299.99 "currency" : USD } ... } }, { "_id" : ObjectId("5c1d358bf383fbee028aea0c"), "product_name" : "Super Suit", "product_attributes" : { "superFlight" : true, "resistance" : [ "Bludgeoning", "Piercing", "Slashing" ] ... }, }
The following operation creates a wildcard index on all scalar fields
(excluding the _id
field):
use inventory db.runCommand( { createIndexes: "products_catalog", indexes: [ { key: { "$**" : 1 }, name: "wildcardIndex" } ] } )
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.
The created index can support queries on any arbitrary field within documents in the collection:
db.products_catalog.find( { "product_price" : { $lt : 25 } } ) db.products_catalog.find( { "product_attributes.elements" : { $eq: "water" } } )
Note
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.
Create a Wildcard Index on Multiple Specific Field Paths
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:
{ "_id" : ObjectId("5c1d358bf383fbee028aea0b"), "product_name" : "Blaster Gauntlet", "product_attributes" : { "price" : { "cost" : 299.99 "currency" : USD } ... } }, { "_id" : ObjectId("5c1d358bf383fbee028aea0c"), "product_name" : "Super Suit", "product_attributes" : { "superFlight" : true, "resistance" : [ "Bludgeoning", "Piercing", "Slashing" ] ... }, }
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.
use inventory db.runCommand( { createIndexes: "products_catalog", indexes: [ { key: { "$**" : 1 }, "wildcardProjection" : { "product_attributes.elements" : 1, "product_attributes.resistance" : 1 }, name: "wildcardIndex" } ] } )
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.
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.
The created index can support queries on any scalar field
included in the wildcardProjection
:
db.products_catalog.find( { "product_attributes.elements" : { $eq: "Water" } } ) db.products_catalog.find( { "product_attributes.resistance" : "Bludgeoning" } )
Note
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.
Create a Wildcard Index that Excludes Multiple Specific Field Paths
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:
{ "_id" : ObjectId("5c1d358bf383fbee028aea0b"), "product_name" : "Blaster Gauntlet", "product_attributes" : { "price" : { "cost" : 299.99 "currency" : USD } ... } }, { "_id" : ObjectId("5c1d358bf383fbee028aea0c"), "product_name" : "Super Suit", "product_attributes" : { "superFlight" : true, "resistance" : [ "Bludgeoning", "Piercing", "Slashing" ] ... }, }
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:
use inventory db.runCommand( { createIndexes: "products_catalog", indexes: [ { key: { "$**" : 1 }, "wildcardProjection" : { "product_attributes.elements" : 0, "product_attributes.resistance" : 0 }, name: "wildcardIndex" } ] } )
While the key pattern "$**"
covers all fields in the document, the
wildcardProjection
field excludes the specified fields from the
index.
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.
The created index can support queries on any scalar field except
those excluded by wildcardProjection
:
db.products_catalog.find( { "product_attributes.maxSpeed" : { $gt: 25 } } ) db.products_catalog.find( { "product_attributes.superStrength" : true } )
Note
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.
Create Index With Commit Quorum
Note
Requires featureCompatibilityVersion 4.4+
Each mongod
in the replica set or sharded cluster
must have featureCompatibilityVersion set to at
least 4.4
to start index builds simultaneously across
replica set members.
MongoDB 4.4 running featureCompatibilityVersion: "4.2"
builds
indexes on the primary before replicating the index build to
secondaries.
Starting with MongoDB 4.4, 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.
Specify the commitQuorum option
to the createIndexes
operation to set the minimum
number of data-bearing voting members (i.e commit quorum), including the
primary, which must complete the index build before the
primary marks the indexes as ready. The default commit quorum is
votingMembers
, or all data-bearing voting replica set members.
The following operation creates an index with a commit quorum of "majority"
, or a
simple majority of data-bearing voting members:
db.getSiblingDB("examples").runCommand( { createIndexes: "invoices", indexes: [ { key: { "invoices" : 1 }, "name" : "invoiceIndex" } ], "commitQuorum" : "majority" } )
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.
Output
The createIndexes
command returns a document that indicates
the success of the operation. The document contains some but not all of
the following fields, depending on outcome:
createIndexes.createdCollectionAutomatically
If
true
, then the collection didn't exist and was created in the process of creating the index.