db.collection.dropIndex()
On this page
Definition
db.collection.dropIndex(index)
Important
mongo Shell Method
This page documents a
mongo
method. This is not the documentation for database commands or language-specific drivers, such as Node.js. To use the database command, see thedropIndexes
command.For MongoDB API drivers, refer to the language-specific MongoDB driver documentation.
Drops or removes the specified index from a collection.
Note
You cannot drop the default index on the
_id
field.Starting in MongoDB 4.2, you cannot specify
db.collection.dropIndex("*")
to drop all non-_id
indexes. Usedb.collection.dropIndexes()
instead.
To get the index name or the index specification document for the
db.collection.dropIndex()
method, use thedb.collection.getIndexes()
method.The
db.collection.dropIndex()
method takes the following parameter:ParameterTypeDescriptionindex
string or documentOptional. 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 index, specify the index name.
Starting in MongoDB 4.2, you cannot specify
"*"
to drop all non-_id
indexes. Usedb.collection.dropIndexes()
instead.New in version 4.4: If an index specified to
db.collection.dropIndex()
is still building,dropIndex()
attempts to abort the in-progress build. Aborting an index build has the same effect as dropping the built index. Prior to MongoDB 4.4,dropIndex()
returned an error if the specified index was still building. See Aborts In-Progress Index Builds for more complete documentation.
Behavior
Starting in MongoDB 4.2, the dropIndex()
operation only kills
queries that are using the index being dropped. This may include
queries considering the index as part of
query planning.
Prior to MongoDB 4.2, dropping an index on a collection would kill all open queries on the collection.
Resource Locking
Changed in version 4.2.
db.collection.dropIndex()
obtains an exclusive lock on the specified collection
for the duration of the operation. All subsequent operations on the
collection must wait until db.collection.dropIndex()
releases the
lock.
Prior to MongoDB 4.2, db.collection.dropIndex()
obtained an exclusive
lock on the parent database, blocking all operations on the
database and all its collections until the operation completed.
Aborts In-Progress Index Builds
New in version 4.4: If an index specified to db.collection.dropIndex()
is still
being built, dropIndex()
attempts to abort
the build. Aborting an index build has the same effect as dropping
the built index. Prior to MongoDB 4.4,
dropIndex()
returned an error if the
specified index was still building.
The index specified to dropIndex()
must be the
only index associated to the index builder, i.e. the indexes built by a
single createIndexes
or
db.collection.createIndexes()
operation. If the associated
index builder has other in-progress builds, wait until the builds
complete and specify the index to dropIndex()
.
For example, a createIndexes
/
createIndexes()
operation creates three
indexes. Assuming all three index builds are still in-progress,
dropIndex()
cannot successfully abort any of
the index builds and therefore cannot drop any of those indexes.
Use currentOp
to identify the index builds associated to a
createIndexes
/ createIndexes()
operation. See Active Indexing Operations for an example.
For replica sets or shard replica sets, aborting an index on the primary
does not simultaneously abort secondary index builds.
dropIndex()
attempts to abort the in-progress
builds for the specified indexes on the primary and if
successful creates an associated "abort" oplog entry. Secondary members with replicated in-progress builds wait for a
commit or abort oplog entry from the primary before either committing or
aborting the index build.
Hidden Indexes
Starting in version 4.4, MongoDB adds the ability to hide or unhide indexes from the query planner. By hiding an index from the planner, users can evaluate the potential impact of dropping an index without actually dropping the index.
If after the evaluation, the user decides to drop the index, the user can drop the hidden index; i.e. you do not need to unhide it first to drop it.
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.
For more information on hidden indexes, see Hidden Indexes.
Example
Consider a pets
collection. Calling the
getIndexes()
method on the pets
collection
returns the following indexes:
[ { "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_" }, { "v" : 2, "key" : { "cat" : -1 }, "name" : "catIdx" }, { "v" : 2, "key" : { "cat" : 1, "dog" : -1 }, "name" : "cat_1_dog_-1" } ]
The single field index on the field cat
has the user-specified name
of catIdx
[1] and the index specification document of
{ "cat" : -1 }
.
To drop the index catIdx
, you can use either the index name:
db.pets.dropIndex( "catIdx" )
Or you can use the index specification document { "cat" : -1 }
:
db.pets.dropIndex( { "cat" : -1 } )
[1] | During index creation, if the user does not
specify an index name, the system generates the name by
concatenating the index key field and value with an underscore,
e.g. cat_1 . |