Single Field Indexes¶

On this page

Example
Cases

MongoDB provides complete support for indexes on any field in a collection of documents. By default, all collections have an index on the _id field, and applications and users may add additional indexes to support important queries and operations.

MongoDB supports indexes that contain either a single field or multiple fields depending on the operations that this index-type supports. This document describes indexes that contain a single field. Consider the following illustration of a single field index.

Diagram of an index on the ``score`` field (ascending).

Example¶

Given the following document in the friends collection:

copy

{ "_id" : ObjectId(...),
  "name" : "Alice"
  "age" : 27
}

The following command creates an index on the name field:

copy

db.friends.ensureIndex( { "name" : 1 } )

Cases¶

`_id` Field Index¶

MongoDB creates the _id index, which is an ascending unique index on the _id field for all collections when the collection is created. You cannot remove the index on the _id field.

Think of the _id field as the primary key for a collection. Every document must have a unique _id field. You may store any unique value in the _id field. The default value of _id is an ObjectId on generated when the client inserts the document. An ObjectId is a 12-byte unique identifier suitable for use as the value of an _id field.

Note

In sharded clusters, if you do not use the _id field as the shard key, then your application must ensure the uniqueness of the values in the _id field to prevent errors. This is most-often done by using a standard auto-generated ObjectId.

Before version 2.2, capped collections did not have an _id field. In version 2.2 and newer, capped collection do have an _id field, except those in the local database. See Capped Collections Recommendations and Restrictions for more information.

Indexes on Embedded Fields¶

You can create indexes on fields embedded in sub-documents, just as you can index top-level fields in documents. Indexes on embedded fields differ from indexes on sub-documents, which include the full content up to the maximum index size of the sub-document in the index. Instead, indexes on embedded fields allow you to use a “dot notation,” to introspect into sub-documents.

Consider a collection named people that holds documents that resemble the following example document:

copy

{"_id": ObjectId(...)
 "name": "John Doe"
 "address": {
        "street": "Main",
        "zipcode": "53511",
        "state": "WI"
        }
}

You can create an index on the address.zipcode field, using the following specification:

copy

db.people.ensureIndex( { "address.zipcode": 1 } )

Indexes on Subdocuments¶

You can also create indexes on subdocuments.

For example, the factories collection contains documents that contain a metro field, such as:

copy

{
  _id: ObjectId("523cba3c73a8049bcdbf6007"),
  metro: {
           city: "New York",
           state: "NY"
         },
  name: "Giant Factory"
}

The metro field is a subdocument, containing the embedded fields city and state. The following creates an index on the metro field as a whole:

copy

db.factories.ensureIndex( { metro: 1 } )

The following query can use the index on the metro field:

copy

db.factories.find( { metro: { city: "New York", state: "NY" } } )

This query returns the above document. When performing equality matches on subdocuments, field order matters and the subdocuments must match exactly. For example, the following query does not match the above document:

copy

db.factories.find( { metro: { state: "NY", city: "New York" } } )

See Query Subdocuments for more information regarding querying on subdocuments.

← Index Types Compound Indexes →

Single Field Indexes¶

Example¶

Cases¶

_id Field Index¶

Indexes on Embedded Fields¶

Indexes on Subdocuments¶

`_id` Field Index¶