Docs Menu

FAQ: Indexes

This document addresses some common questions regarding MongoDB indexes. For more information on indexes, see indexes.

To create an index on a collection, use the db.collection.createIndex() method. Creating an index is an administrative operation. In general, applications should not call db.collection.createIndex() on a regular basis.

注意

Index builds can impact performance; see How does an index build affect database performance?. Administrators should consider the performance implications before building indexes.

MongoDB index builds against a populated collection require an exclusive read-write lock against the collection. Operations that require a read or write lock on the collection must wait until the mongod releases the lock.

  • For feature compatibility version (fcv) "4.2", MongoDB uses an optimized build process that only holds the exclusive lock at the beginning and end of the index build. The rest of the build process yields to interleaving read and write operations.

  • For feature compatibility version (fcv) "4.0", the default foreground index build process holds the exclusive lock for the entire index build. background index builds do ではない take an exclusive lock during the build process.

インデックス構築プロセスの詳細については、「入力済みコレクションでのインデックス構築」を参照してください。

Index builds on replica sets have specific performance considerations and risks. See 複製された環境でのインデックス構築 for more information. To minimize the impact of building an index on replica sets, including shard replica sets, use a rolling index build procedure as described in Create a Rolling Index Build on Replica Sets.

To return information on currently running index creation operations, see アクティブなインデックス操作.

To terminate an in-progress index build, use the db.collection.dropIndex() or its shell helpers dropIndex() or dropIndexes. Do not use db.killOp() to terminate in-progress index builds in replica sets or sharded clusters.

You cannot terminate a replicated index build on secondary members of a replica set. You must first drop the index on the primary. The primary stops the index build and creates an associated abortIndexBuild oplog entry. Secondaries that replicate the abortIndexBuild oplog entry stop the in-progress index build and discard the build job.

To learn more, see 進行中のインデックスビルドの停止.

To list a collection's indexes, use the db.collection.getIndexes() method.

To inspect how MongoDB processes a query, use the explain() method.

A number of factors determine which fields to index, including selectivity and the support for multiple query shapes. For more information, see Operational Considerations for Indexes and インデックスの作成に関する戦略.

The db.collection.stats() includes an indexSizes document which provides size information for each index on the collection.

Write operations may require updates to indexes:

  • If a write operation modifies an indexed field, MongoDB updates all indexes that have the modified field as a key.

Therefore, if your application is write-heavy, indexes might affect performance.

インデックス フィールドで大量の無作為データ(例: ハッシュされたインデックス)の挿入操作が実行される場合、挿入パフォーマンスが低下することがあります。無作為データを一括挿入すると、無作為のインデックスエントリが作成され、インデックスのサイズが増大します。無作為な挿入ごとに別のインデックスエントリへのアクセスが必要なサイズにインデックスが達した場合、挿入により WiredTiger キャッシュがエビクションおよび置き換えられる率が上昇します。こうした場合、インデックスは完全にキャッシュされなくなり、ディスク上で更新されるため、パフォーマンスが低下します。

インデックス フィールドでの無作為データの一括挿入動作を向上させるには、次のいずれかを実行します。

  • インデックスを削除し、無作為データを挿入した後に再度作成します。

  • インデックスのない空のコレクションにデータを挿入します。

一括挿入後にインデックスを作成すると、メモリ内のデータがソートされ、すべてのインデックスに対して順序付き挿入が実行されます。

Only use a rolling index build if your deployment matches one of the following cases:

  • If your average CPU utilization exceeds (N-1)/N-10% where where N is the number of CPU threads available to mongod

  • If your WiredTiger cache fill ratio regularly exceeds 90%

注意

If your deployment does not meet this criteria, use the default index build.

Tip

With Atlas, you can temporarily scale your cluster to meet the requirements for a traditional index build. However, Atlas charges to scale your cluster. See Cluster Configuration Costs for more information.