For AI agents: a documentation index is available at https://www.mongodb.com/docs/llms.txt — markdown versions of all pages are available by appending .md to any URL path.
Docs Menu

Shard Key Indexes

Sharded collections require an index that supports the shard key. The index can be an index on the shard key or a compound index where the shard key is a prefix of the index.

  • If the collection is empty, sh.shardCollection() creates the index on the shard key if such an index does not already exists.

  • If the collection is not empty, you must create the index first before using sh.shardCollection().

  • If you reshard a collection using sh.reshardCollection(), you do not need to create the index on the new shard key beforehand. The resharding operation builds the required indexes automatically. To learn more, see the Reshard a Collection procedure.

You cannot drop or hide an index if it is the only non-hidden index that supports the shard key.

Starting in MongoDB 7.0.3, 6.0.12, and 5.0.22, you can drop the index for a hashed shard key. For details, see Drop a Hashed Shard Key Index.

MongoDB can enforce a uniqueness constraint on a ranged shard key index. Using a unique index on the shard key enforces uniqueness on the entire key combination and not individual components of the shard key.

For a ranged sharded collection, only the following indexes can be unique:

  • The index on the shard key

  • A compound index where the shard key is a prefix

  • The default _id index; however, the _id index only enforces the uniqueness constraint per shard if the _id field is not the shard key.

Important

Sharded clusters do not enforce the uniqueness constraint on _id fields across the cluster when the _id field is not the shard key.

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.

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.

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.

The unique index constraints mean that:

  • For a to-be-sharded collection, you cannot shard the collection if the collection has multiple unique indexes unless the shard key is the prefix for all the unique indexes.

  • For an already-sharded collection, you cannot create unique indexes on other fields unless the shard key is included as the prefix.

  • A unique index stores a null value for a document missing the indexed field; that is a missing index field is treated as another instance of a null index key value. For more information, see Missing Document Field in a Unique Single-Field Index.

To enforce uniqueness on the shard key values, pass the unique parameter as true to the sh.shardCollection() method:

  • If the collection is empty, sh.shardCollection() creates the unique index on the shard key if such an index does not already exist.

  • If the collection is not empty, you must create the index first before using sh.shardCollection().

Although you can have a unique compound index where the shard key is a prefix, if using unique parameter, the collection must have a unique index that is on the shard key.

You cannot specify a unique constraint on a hashed index.

To maintain uniqueness on a field that is not your shard key, see Unique Constraints on Arbitrary Fields.

On this page