Definition
createIndexes
Builds one or more indexes on a collection.
Tip
In
mongosh
, this command can also be run through thedb.collection.createIndex()
anddb.collection.createIndexes()
helper methods.Helper methods are convenient for
mongosh
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.
Compatibility
This command is available in deployments hosted in the following environments:
- MongoDB Atlas: The fully managed service for MongoDB deployments in the cloud
Note
This command is supported in all MongoDB Atlas clusters. For information on Atlas support for all commands, see Unsupported Commands.
- MongoDB Enterprise: The subscription-based, self-managed version of MongoDB
- MongoDB Community: The source-available, free-to-use, and self-managed version of MongoDB
Syntax
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>
}
)
Command Fields
The createIndexes
command takes the following fields:
Field | Type | Description |
---|---|---|
| string | The collection for which to create indexes. |
| array | Specifies the indexes to create. Each document in the array specifies a separate index. |
| document | Optional. A document expressing the write concern. Omit to use the default write concern. |
| integer or string | Optional. 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 Starting in MongoDB v5.0, you can resume some interrupted index builds when the Replica set nodes in a commit quorum must have Supports the following values:
|
| any | Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:
A comment can be any valid BSON type (string, integer, object, array, etc). |
Each document in the indexes
array can take the following fields:
Field | Type | Description |
---|---|---|
| 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. If specifying direction, specify MongoDB supports several different index types, including: See index types for more information. Wildcard indexes support workloads where users query against custom fields or a large variety of fields in a collection:
|
| string | A name that uniquely identifies the index. |
| 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 The option is unavailable for hashed indexes. |
| document | Optional. If specified, the index only references documents that match the filter expression. See Partial Indexes for more information. A filter expression can include:
If you are using Client-Side Field Level Encryption or Queryable Encryption, a You can specify a |
| boolean | Optional. If The following index types are sparse by default and ignore this option: For a compound index that includes MongoDB provides the option to create partial indexes. These offer a superset of the functionality of sparse indexes and are preferred instead. |
| integer | Optional. Specifies a value, in seconds, as a time to live (TTL) to control how long MongoDB retains documents in this collection. This option only applies to TTL indexes. See Expire Data from Collections by Setting TTL for more information. If you use TTL indexes created before MongoDB 5.0, or if you want to sync data created in MongDB 5.0 with a pre-5.0 installation, see Indexes Configured Using NaN to avoid misconfiguration issues. The TTL index |
boolean | 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. Default is | |
| document | Optional. Allows users to configure the storage engine on a per-index basis when creating an index. The
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. |
| document | Optional. 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 Assign Weights to Text Search Results on Self-Managed Deployments to adjust the scores. The default value is |
| string | Optional. For text indexes, the language that determines the list of stop words and the rules for the stemmer and tokenizer. See Text Search Languages on Self-Managed Deployments for the available languages and Specify the Default Language for a Text Index on Self-Managed Deployments for more information and examples. The default value is |
| string | Optional. For text indexes, the name of the field, in the collection's documents, that contains the override language for the document. The default value is |
| integer | Optional. The For available versions, see Text Index Versions on Self-Managed Deployments. |
| integer | Optional. The For the available versions, see 2dsphere Indexes. |
| integer | Optional. For 2d indexes, the number of precision of the stored geohash value of the location data. The |
| number | Optional. For 2d indexes, the lower inclusive boundary for the longitude and latitude values. The default value is |
| number | Optional. For 2d indexes, the upper inclusive boundary for the longitude and latitude values. The default value is |
| document | Optional. 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:
The collation option has the following syntax:
When specifying collation, the |
| document | Optional. Allows users to include or exclude specific field paths from a wildcard index using the The
The
Wildcard indexes omit the
All of the statements in the |
mongosh
provides the methods db.collection.createIndex()
and db.collection.createIndexes()
as wrappers for the createIndexes
command.
Considerations
MongoDB disallows the creation of version 0 indexes.
Index Names
The createIndexes
command and mongosh
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.
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.
Use the setIndexCommitQuorum
command to modify the commit quorum of an in-progress index build.
Collation and Index Types
The following indexes only support simple binary comparison and do not support collation:
Tip
To create a text
or 2d
index on a collection that has a non-simple collation, you must explicitly specify {collation: {locale: "simple"} }
when creating the index.
Stable API
When using Stable API V1:
You cannot specify any of the following fields in the
indexes
array:background
bucketSize
sparse
storageEngine
- You cannot create text indexes.
The above unsupported index types are ignored by the query planner in strict mode. For example, attempting to use a
sparse
index withcursor.hint()
will result in the followingBadValue
error:planner returned error :: caused by :: hint provided does not
correspond to an existing indexBehavior
Concurrency
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 untilcreateIndexes
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.Important
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.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 build indexes. The default memory limit is 200 megabytes percreateIndexes
command, shared equally among all indexes built in that command. For example, if you build 10 indexes with onecreateIndexes
command, MongoDB allocates each index 20 megabytes for the index build process when using the default memory limit of 200. When you reach the memory limit, MongoDB creates temporary files in the_tmp
subdirectory within--dbpath
to complete the build.You can adjust the memory limit with the
maxIndexBuildMemoryUsageMegabytes
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.Each
createIndexes
command has a limit ofmaxIndexBuildMemoryUsageMegabytes
. When using the defaultmaxNumActiveUserIndexBuilds
of 3, the total memory usage for all concurrent index builds can reach up to 3 times the value ofmaxIndexBuildMemoryUsageMegabytes
.Index Options
Non-Hidden Option
The hidden option can be changed without dropping and recreating the index. See Hidden Option.
Changing Index Options
Collation options on an existing index can be updated. To change other index options, drop the existing index with
db.collection.dropIndex()
then runcreateIndexes
with the new options.Collation Option
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
of1
or2
, you can create a case-insensitive index. Index with a collationstrength
of1
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.
A
restaurants
collection has the following documents:db.restaurants.insertMany( [
{ _id: 1, category: "café", status: "Open" },
{ _id: 2, category: "cafe", status: "open" },
{ _id: 3, category: "cafE", status: "open" }
] )The
restaurants
collection has an index on a string fieldcategory
with the collation locale"fr"
.db.restaurants.createIndex( { category: 1 }, { collation: { locale: "fr" } } )
The following query, which specifies the same collation as the index, can use the index:
db.restaurants.find( { category: "cafe" } ).collation( { locale: "fr" } )
However, the following query operation, which by default uses the "simple" binary collator, cannot use the index:
db.restaurants.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
restaurants
has a compound index on the numeric fieldsscore
andprice
and the string fieldcategory
; the index is created with the collation locale"fr"
for string comparisons:db.restaurants.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.restaurants.find( { score: 5 } ).sort( { price: 1 } )
db.restaurants.find( { score: 5, price: { $gt: Decimal128( "10" ) } } ).sort( { price: 1 } )The following operation, which uses
"simple"
binary collation for string comparisons on the indexedcategory
field, can use the index to fulfill only thescore: 5
portion of the query:db.restaurants.find( { score: 5, category: "cafe" } )
To confirm whether a query used an index, run the query with the
explain()
option.Important
Matches against document keys, including embedded document keys, use simple binary comparison. This means that a query for a key like "type.café" will not match the key "type.cafe", regardless of the value you set for the strength parameter.
Hidden Option
To change the
hidden
option for existing indexes, you can use the followingmongosh
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 } );
Tip
Wildcard Indexes
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
}
}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.Wildcard indexes do not support:
- 2d (Geospatial) indexes
- 2dsphere (Geospatial) indexes
- Hashed indexes
- Time to Live (TTL) indexes
- Text indexes
- Unique indexes
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.Starting in MongoDB 7.0, wildcard indexes support ascending (
1
) and descending (-1
) sort order. Earlier versions only supported ascending order.
To learn more, see:
Transactions
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.Commit Quorum Contrasted with Write Concern
There are important differences between commit quorums and write concerns:
- Index builds use commit quorums.
- Write operations use write concerns.
Each data-bearing node in a cluster is a voting member.
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.
The write concern is the level of acknowledgment that the write has propagated to the specified number of instances.
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.
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.
Example
The following command builds two indexes on the
inventory
collection of theproducts
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
Note
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
- Create a Wildcard Index on All Field Paths
- Create a Wildcard Index on Multiple Specific Field Paths
- Create a Wildcard Index that Excludes Multiple Specific Field Paths
Create a Wildcard Index on a Single Field Path
Consider a collection
products_catalog
where documents may contain aproduct_attributes
field. Theproduct_attributes
field can contain arbitrary nested fields, including embedded documents and arrays:db.products_catalog.insertMany( [
{
_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 aproduct_attributes
field. Theproduct_attributes
field can contain arbitrary nested fields, including embedded documents and arrays:db.products_catalog.insertMany( [
{
_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 thewildcardProjection
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 aproduct_attributes
field. Theproduct_attributes
field can contain arbitrary nested fields, including embedded documents and arrays:db.products_catalog.insertMany( [
{
_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 theproduct_attributes.elements
andproduct_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, thewildcardProjection
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 onwildcardProjection
, see the parameter documentation.Create a Wildcard Index that Excludes Multiple Specific Field Paths
Consider a collection
products_catalog
where documents may contain aproduct_attributes
field. Theproduct_attributes
field can contain arbitrary nested fields, including embedded documents and arrays:db.products_catalog.insertMany( [
{
_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 theproduct_attributes.elements
andproduct_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, thewildcardProjection
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 onwildcardProjection
, 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 least4.4
to start index builds simultaneously across replica set members.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 set the commit quorum, use
createIndexes
to specify thecommitQuorum
value.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 isvotingMembers
, which means all data-bearing members.The following operation creates an index with a commit quorum of
"majority"
, or a simple majority of data-bearing 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.
createIndexes.note
This
note
is returned if an existing index or indexes already exist. This indicates that the index was not created or changed.
Output Example
The following code block illustrates an example of the
createIndexes
output on a sharded cluster. On a sharded cluster,createIndexes
outputs araw
embedded document which contains a document for each shard the index is built on. The keys of theraw
embedded document are concantenations of shard id and the hostname and port of the individual nodes that make up the shard.{
raw: {
'atlas-2m11gv-shard-1/atlas-2m11gv-shard-01-00.cpfgx.mongodb.net:27017,atlas-2m11gv-shard-01-01.cpfgx.mongodb.net:27017,atlas-2m11gv-shard-01-02.cpfgx.mongodb.net:27017': {
numIndexesBefore: 3,
numIndexesAfter: 5,
createdCollectionAutomatically: false,
commitQuorum: 'votingMembers',
ok: 1
},
'atlas-2m11gv-shard-0/atlas-2m11gv-shard-00-00.cpfgx.mongodb.net:27017,atlas-2m11gv-shard-00-01.cpfgx.mongodb.net:27017,atlas-2m11gv-shard-00-02.cpfgx.mongodb.net:27017': {
numIndexesBefore: 3,
numIndexesAfter: 5,
createdCollectionAutomatically: false,
commitQuorum: 'votingMembers',
ok: 1
}
},
ok: 1,
'$clusterTime': {
clusterTime: Timestamp({ t: 1743624296, i: 7 }),
signature: {
hash: Binary.createFromBase64('22j0GK8SIK806T+0OdCY6qYHocM=', 0),
keyId: Long('7438621020069560323')
}
},
operationTime: Timestamp({ t: 1743624296, i: 7 })
}