Docs Menu
Docs Home
/
MongoDBマニュアル
/ / /

db.collection.createIndexes()

項目一覧

  • 定義
  • 互換性
  • Stable API
  • オプション
  • すべてのインデックス タイプのオプション
  • 照合のオプション
  • textインデックスのオプション
  • 2dsphere インデックスのオプション
  • 2d インデックスのオプション
  • wildcard インデックスのオプション
  • 動作
  • 既存インデックスの再作成
  • インデックス オプション
  • ワイルドカード インデックス
  • トランザクション
  • インデックス構築
  • オプションなしのインデックスの作成
  • 照合が指定されたインデックスの作成
  • ワイルドカード インデックスの作成
  • コミットクォーラムを使用したインデックスの作成
  • 複数のインデックスの作成
  • 詳細情報

MongoDB とドライバー

このページでは、 mongosh メソッドについて説明します。MongoDB ドライバーで同等のメソッドを確認するには、ご使用のプログラミング言語の対応するページを参照してください。

C#Java SyncNode.jsPyMongoCC++GoJava RSKotlin CoroutineKotlin SyncPHPMotorMongoidRustScalaSwift
db.collection.createIndexes( [ keyPatterns ], options, commitQuorum )

コレクションに 1 つ以上のインデックスを作成します。

レプリカセットおよびシャーディングされたクラスターへのインデックス ビルドの影響を最小限に抑えるには、「 レプリカセットでのローリング インデックス ビルド 」で説明されているローリング インデックスのビルド手順を使用してください。

db.collection.createIndexes() は以下のパラメーターを取ります。

Parameter
タイプ
説明
keyPatterns
ドキュメント

インデックス仕様ドキュメントを含む配列。各ドキュメントには、フィールドと値のペアが含まれています。フィールドはインデックスキーで、値はそのフィールドのインデックスのタイプを表します。フィールドの昇順インデックスの場合は 1 の値を指定し、降順インデックスの場合は -1 の値を指定します。

MongoDB は、次のような多彩なインデックス タイプをサポートしています。

詳細については、「インデックス タイプ」を参照してください。

ワイルドカード インデックスは、ユーザーがカスタム フィールドまたはコレクション内の多種多様なフィールドに対してクエリを実行するワークロードをサポートします。

  • ワイルドカード インデックスは、特定のフィールドとそのサブパス、またはドキュメント内のすべてのフィールドで作成できます。

    詳しくは、「ワイルドカード インデックス」を参照してください。

options
ドキュメント
任意。 インデックスの作成を制御する一連のオプションを含むドキュメント。 詳細については、「オプション 」を参照してください。
整数または文字列

任意。データを保持する投票レプリカセット ノードの最小数(コミットクォーラム)で、プライマリが indexes を準備完了とマークする前に、インデックス構築の成功を報告する必要があるもの(プライマリを含む)を指します。「投票」ノードとは、members[n].votes0 より大きい任意のレプリカセット ノードです。

次の値をサポートします。

  • "votingMembers" - データを保持するすべての投票レプリカセット ノード(デフォルト)。

  • "majority" - データを保持する単純過半数の投票レプリカセット ノード。

  • <int> - データを保持する特定数の投票レプリカセット ノード。

  • 0 - クォーラム投票の動作を無効にします。ノードはインデックス構築を同時に開始しますが、インデックス構築を完了する前にクォーラムの投票や待機は行いません0 のコミットクォーラムでインデックス構築を開始した場合、後で setIndexCommitQuorum を使用してコミットクォーラムを変更することはできません。

  • レプリカセットのタグ名

このメソッドは、次の環境でホストされている配置で使用できます。

  • MongoDB Atlas はクラウドでの MongoDB 配置のためのフルマネージド サービスです

注意

このコマンドは、すべての MongoDB Atlas クラスターでサポートされています。すべてのコマンドに対する Atlas のサポートについては、 「サポートされていないコマンド」を参照してください。

  • MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン

  • MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン

Stable API V1 を使用する場合

  • optionsドキュメントでは次のフィールドは指定できません。

    • background

    • bucketSize

    • sparse

    • storageEngine

  • geoHaystackまたはテキストインデックスは作成できません。

  • 上記でサポートされていないインデックス タイプは、 厳密モード の クエリ プランナー によって無視されます。たとえば、 cursor.hint()sparseインデックスを使用しようとすると、次のBadValueエラーが発生します。

    planner returned error :: caused by :: hint provided does not
    correspond to an existing index

options ドキュメントには、インデックスの作成を制御する一連のオプションが含まれています。異なるインデックス タイプには、そのタイプに固有の追加オプションがある場合があります。

同じドキュメント内で複数のインデックスオプションを指定できます。ただし、複数のオプション ドキュメントを指定すると、db.collection.createIndexes() 操作は失敗します。

次の db.collection.createIndexes() 操作を考えてみましょう。

db.collection.createIndexes(
[
{
"a": 1
},
{
"b": 1
}
],
{
unique: true,
sparse: true,
expireAfterSeconds: 3600
}
)

オプションの仕様がこのように複数のドキュメントに分割されていた場合 ({ unique: true }, { sparse: true, expireAfterSeconds: 3600 })、インデックス作成操作は失敗していたでしょう。

重要

db.collection.createIndexes()にオプションを指定すると、指定されたすべてのインデックスにオプションが適用されます。 たとえば、 照合 オプションを指定すると、作成されたすべてのインデックスにその照合が含まれます。

db.collection.createIndexes() は、互換性のないオプションや多すぎる引数でインデックスを作成しようとするとエラーを返します。詳しくは、オプションの説明を参照してください。

以下のオプションは、特に指定がない限り、すべてのインデックス タイプで使用できます。

Parameter
タイプ
説明
unique
ブール値

任意。keyPatterns 配列で指定された各インデックスが一意なインデックスであることを指定します。一意なインデックスは、インデックス キー値がインデックス内の既存の値と一致するドキュメントの挿入または更新を受け付けません。

ユニークインデックスを作成するには、true を指定します。デフォルト値は false です。

このオプションはハッシュされたインデックスには使用できません

name
string

任意。インデックスの名前。指定しない場合、MongoDB はインデックス フィールドの名前とソート順序を連結してインデックス名を生成します。

db.collection.createIndexes() に指定されたオプションは、キー パターン配列に含まれるすべてのインデックス指定に適用されます。インデックス名は一意である必要があるため、db.collection.createIndexes() を使用して 1 つのインデックスを作成する場合にのみ name を指定できます

partialFilterExpression
ドキュメント

任意。指定すると、インデックスはフィルター式に一致するドキュメントのみを参照します。詳細については、「部分インデックス」を参照してください。

フィルター式には、次の要素を含めることができます。

MongoDB ではすべてのインデックス タイプpartialFilterExpression オプションを指定できます。

sparse
ブール値

任意。true の場合、インデックスは指定されたフィールドを持つドキュメントのみを参照します。これらのインデックスは使用するスペースが少なくなりますが、状況によっては動作が異なります(特にソート)。デフォルト値は false です。詳細については、「スパース インデックス」を参照してください。

次のインデックス タイプはデフォルトでスパースであり、このオプションを無視します。

2dsphere インデックスキーと他のタイプのキーを含む複合インデックスの場合、インデックスがドキュメントを参照するかどうかは 2dsphere インデックスフィールドだけで決まります。

部分インデックスには、sparse index 機能のスーパーセットがあります。アプリケーションに特別な要件がない限り、sparse index ではなく、部分インデックスを使用してください。

expireAfterSeconds
integer

任意。MongoDB がこのコレクション内のドキュメントを保持する期間を制御するための有効期間(TTL)の値を秒単位で指定します。このオプションは TTL インデックスにのみ適用されます。詳細については、「TTL によるコレクションのデータ期限設定」を参照してください。

MongoDB 5.0 より前のバージョンで作成された TTL インデックスを使用する場合、または MongDB 5.0 で作成されたデータを 5.0 より前のインストールと同期する場合は、「NaN を使用して構成されたインデックス」を参照して誤った構成の問題を回避してください。

TTLインデックスの expireAfterSeconds 値は、0 から 2147483647 の範囲内(両端を含む)である必要があります。

ブール値

任意。インデックスがクエリ プランナーから非表示かどうかを決定するブール値。非表示インデックスは、クエリプランの選択において評価されません。

デフォルトは、false に設定されています。

storageEngine
ドキュメント

任意。作成されたインデックスのストレージ エンジンをユーザーが設定できるようにします。

storageEngine オプションは次のような形式をとります。

storageEngine: { <storage-engine-name>: <options> }

インデックスの作成時に指定されたストレージエンジン構成オプションは、異なるストレージエンジンを使用するノードのあるレプリカセットをサポートするために、レプリケーション中に検証され、oplog に記録されます。

Parameter
タイプ
説明
collation
ドキュメント

任意。インデックスの照合を指定します。

照合を指定すると、大文字・小文字やアクセント記号など、文字列を比較するための言語独自のルールを指定できます。

コレクション レベルで照合を指定した場合、次のようになります。

  • インデックスの作成時に照合を指定しない場合、MongoDB はコレクションのデフォルトの照合でインデックスを作成します。

  • インデックスの作成時に照合を指定する場合、MongoDB は指定された照合でインデックスを作成します。

照合オプションの構文は次のとおりです。

collation: {
locale: <string>,
caseLevel: <boolean>,
caseFirst: <string>,
strength: <int>,
numericOrdering: <boolean>,
alternate: <string>,
maxVariable: <string>,
backwards: <boolean>
}

照合を指定する場合、locale フィールドは必須ですが、その他の照合フィールドはすべて任意です。フィールドの説明については、照合ドキュメントを参照してください。

次のインデックスは単純なバイナリ比較のみをサポートしており、照合はサポートしていません。

Tip

単純ではない照合順序を持つコレクションに text または 2d インデックスを作成するには、インデックスの作成時、明確に {collation: {locale: "simple"} } を指定する必要があります。

コレクション レベルで照合を指定した場合、次のようになります。

  • インデックスの作成時に照合を指定しない場合、MongoDB はコレクションのデフォルトの照合でインデックスを作成します。

  • インデックスの作成時に照合を指定する場合、MongoDB は指定された照合でインデックスを作成します。

Tip

照合の strength1 または 2 に指定すると、大文字と小文字を区別しないインデックスを作成できます。照合の strength1 のインデックスは、発音と大文字・小文字の両方を区別しません。

同じキーに対して、異なる照合を持つ複数のインデックスを作成できます。同じキー パターンで照合が異なるインデックスを作成するには、ユニークインデックス名を設定する必要があります。

文字列の比較にインデックスを使用するには、操作で同じ照合も指定する必要があります。つまり、照合順序を持つインデックスでは、操作で異なる照合順序が指定されている場合、インデックス付きフィールドで文字列比較を実行する操作をサポートできません。

警告

照合が構成されたインデックスは、並べ替え順序を実現するために ICU 照合キーを使用するため、照合対応のインデックス キーは、照合のないインデックスのインデックス キーよりも大きくなる可能性があります。

たとえば、コレクション myColl には、照合ロケール "fr" を持つ文字列フィールド category のインデックスがあります。

db.myColl.createIndex( { category: 1 }, { collation: { locale: "fr" } } )

インデックスと同じ照合を指定する次のクエリ操作では、インデックスを使用できます。

db.myColl.find( { category: "cafe" } ).collation( { locale: "fr" } )

ただし、デフォルトで「シンプル」なバイナリー コレータを使用する次のクエリ操作では、インデックスを使用できません。

db.myColl.find( { category: "cafe" } )

インデックス プレフィックスキーが文字列、配列、および埋め込みドキュメントではない複合インデックスの場合でも、異なる照合を指定する操作では、インデックスを使用してインデックス プレフィックスキーの比較をサポートできます。

たとえば、myColl コレクションには、数値フィールドの scoreprice、および 文字列フィールドの category の複合インデックスがあります。このインデックスは、文字列比較用の照合ロケール "fr" を使用して作成されます。

db.myColl.createIndex(
{ score: 1, price: 1, category: 1 },
{ collation: { locale: "fr" } } )

文字列の比較に "simple" バイナリ照合を使用する次の操作では、インデックスを使用できます。

db.myColl.find( { score: 5 } ).sort( { price: 1 } )
db.myColl.find( { score: 5, price: { $gt: NumberDecimal( "10" ) } } ).sort( { price: 1 } )

次の操作では、"simple" バイナリ照合を使用してインデックス付きの category フィールドで文字列を比較しますが、クエリの score: 5 部分の実行についてはインデックスが使用できます。

db.myColl.find( { score: 5, category: "cafe" } )

重要

ドキュメント キーとの照合(埋め込みドキュメントのキーを含む)では、単純なバイナリ比較が使用されます。つまり、"foo.bár" のようなキーのクエリは、strength パラメーターに設定した値にかかわらず、キー "foo.bar" と一致しません。

次のオプションはテキストインデックスのみに使用できます。

Parameter
タイプ
説明
weights
ドキュメント

任意。 テキストインデックスの場合、フィールドと重みを含むドキュメントが組み合わされます。 重みは1から99までの整数で、 999はスコアに関して他のインデックス付きフィールドと比較したフィールドの重要性を示します。 重みはインデックス フィールドの一部またはすべてに指定できます。 スコアを調整するには、「自己管理型配置のテキスト検索結果への重みの割り当て」を参照してください。 デフォルト値は1です。

MongoDB 5.0 以降、重みオプションはテキスト インデックスにのみ使用できます。

default_language
string
任意。 テキストインデックスで、ストップワードのリストとステマーとトークナイザのルールを決定する言語。 使用可能な言語については「 自己管理型配置のテキスト検索言語」を、詳細と例については「 自己管理型配置のテキストインデックスのデフォルト言語の指定」を参照してください。 デフォルト値はenglishです。
language_override
string
任意。 テキストインデックスの場合、ドキュメントの上書き言語を含む、コレクション内のドキュメントのフィールド名です。 デフォルト値はlanguageです。 例については、「自己管理型配置のテキストインデックスのデフォルト言語の指定」を参照してください。
textIndexVersion
integer

任意。text インデックスのバージョン番号。ユーザーはこのオプションを使用してデフォルトのバージョン番号を上書きできます。

使用可能なバージョンについては、「自己管理型配置のテキストインデックス バージョン 」を参照してください。

次のオプションは 2dsphere インデックスのみに使用できます。

Parameter
タイプ
説明
2dsphereIndexVersion
integer

任意。2dsphere インデックスのバージョン番号。ユーザーはこのオプションを使用してデフォルトのバージョン番号を上書きできます。

使用可能なバージョンについては、「2dsphere インデックス」を参照してください。

次のオプションは、2d インデックスに対してのみ使用できます。

Parameter
タイプ
説明
bits
integer

任意。2d インデックスの場合、保存された位置データのジオハッシュ値の精度の数。

bits 値の範囲は 1 から 32 まで(32 を含む)です。デフォルト値は 26 です。

min
数値
任意。2d インデックスで、経度と緯度の境界(下限を含む)。デフォルト値は -180.0 です。
max
数値
任意。2d インデックスで、経度と緯度の値の境界(上限を含む)デフォルト値は 180.0 です。

次のオプションはワイルドカード インデックスでのみ使用できます。

Parameter
タイプ
説明
wildcardProjection
ドキュメント

任意。特定のフィールドパスを ワイルドカード インデックス に含めたり除外したりできるようにします。

このオプションは、すべてのドキュメント フィールドにワイルドカード インデックスを作成する場合にのみ有効です。特定のフィールド パスとそのサブフィールドにワイルドカード インデックスを作成する場合には、wildcardProjection オプションは指定できません。

wildcardProjection 次のような仕様で動作します。

{ "$**": 1 }
{ "userID":, "$**": 1 }

ただし、ワイルドカード フィールドと通常の(ワイルドカード以外の)フィールドに同じフィールドを含むインデックスを定義することはできません。 インデックスを正しく定義するには、wildcardProjection を使用して重複するフィールドをワイルドカード パターンから除外します。

wildcardProjection は次のような仕様では動作しません。

``{ "path.to.field.$**" : 1 }``

wildcardProjection オプションは次のような形式をとります。

wildcardProjection: {
"path.to.field.a" : <value>,
"path.to.field.b" : <value>
}

<value> は次のいずれかになります。

  • 1 または true の場合は、ワイルドカード インデックスにフィールドが追加されます。

  • 0 または false の場合は、ワイルドカード インデックスからフィールドが除外されます。

ワイルドカード インデックスでは、デフォルトで _id フィールドが省略されます。_id フィールドをワイルドカード インデックスに含めるには、wildcardProjection ドキュメントに明示的に含める必要があります。

{
"wildcardProjection" : {
"_id" : 1,
"<field>" : 0|1
}
}

wildcardProjection ドキュメント内のすべてのステートメントは、包含ステートメントまたは除外ステートメントのいずれかである必要があります。除外ステートメントに _id フィールドを含めることもできます。これは、このルールの唯一の例外です。

db.collection.createIndexes()に指定されたオプションは、キー パターン配列に含まれるすべてのインデックス指定に適用されます。 db.collection.createIndexes()を使用して単一のワイルドカード インデックスを作成する場合にのみwildcardProjectionを指定します。

すでに存在するインデックスに対してdb.collection.createIndexes()を呼び出す場合、MongoDB は既存のインデックスを再度作成しません。

照合オプションは除き、1 つのインデックスオプションセットを使用してインデックスを作成し、その後別のインデックスオプションを使用して同じインデックスを再作成しようとすると、MongoDB はオプションを変更せず、インデックスを再作成しません。

非表示オプションはインデックスを削除して再度作成することなく変更できます。詳細は、「非表示オプション」を参照してください。

その他のインデックス オプションを変更するには、新しいオプションで を実行する前に、db.collection.dropIndex() db.collection.createIndexes()で既存のインデックスを削除します。

同じキーに対して、異なる照合を持つ複数のインデックスを作成できます。同じキー パターンで照合が異なるインデックスを作成するには、ユニークインデックス名を設定する必要があります。

既存のインデックスを非表示または再表示するには、次のmongoshメソッドを使用できます。

たとえば、

  • インデックスの hidden オプションを true に変更するには、db.collection.hideIndex() メソッドを使用します。

    db.restaurants.hideIndex( { borough: 1, ratings: 1 } );
  • インデックスの hidden オプションを false に変更するには、db.collection.unhideIndex() メソッドを使用します。

    db.restaurants.unhideIndex( { borough: 1, city: 1 } );

Tip

以下も参照してください。

  • ワイルドカード インデックスでは、デフォルトで _id フィールドが省略されます。_id フィールドをワイルドカード インデックスに含めるには、wildcardProjection ドキュメントに明示的に含める必要があります。

    {
    "wildcardProjection" : {
    "_id" : 1,
    "<field>" : 0|1
    }
    }

    wildcardProjection ドキュメント内のすべてのステートメントは、包含ステートメントまたは除外ステートメントのいずれかである必要があります。除外ステートメントに _id フィールドを含めることもできます。これは、このルールの唯一の例外です。

  • ワイルドカード インデックスは次のインデックスをサポートしていません。

    ワイルドカード インデックスはスパースインデックスです。インデックス付きフィールドがない場合は、クエリをサポートしません。ワイルドカード フィールドに null 値がある場合、ワイルドカード インデックスはドキュメントにインデックスを作成します。

    MongoDB 7.0 以降、ワイルドカード インデックスで昇順(1)と降順(-1)のソート順序がサポートされます。以前のバージョンでは、昇順のみがサポートされていました。

詳しくは以下を参照してください。

トランザクションがクロスシャード間書込みトランザクション(write transaction)でない場合に、分散トランザクション内にコレクションとインデックスを作成できます。

トランザクションで db.collection.createIndexes() を使用するには、そのトランザクションで読み取り保証(read concern)"local" を使用する必要があります。読み取り保証レベルを "local" 以外に指定すると、トランザクションは失敗します。

バージョン 7.1 で変更

MongoDB 7.1 以降では、インデックス構築でのエラー報告が高速化され、障害回復力が高まります。 新しいindexBuildMinAvailableDiskSpaceMBパラメータを使用して、インデックスビルドに必要な最小ディスク容量を設定することもできます。これにより、ディスク容量が低すぎる場合はインデックスビルドが停止します。

次の表は、MongoDB 7.1 以降と以前のバージョンのインデックス構築動作を比較したものです。

MongoDB 7.1 以降の 動作
以前の MongoDB バージョンでの動作
重複キー エラーを除く、コレクションスキャンフェーズ中に見つかったインデックス エラーは直ちに返され、その後インデックスのビルドは停止します。 以前の MongoDB バージョンでは、インデックスビルドの終了間際に発生するコミットフェーズでエラーが返されます。 MongoDB 7.1 は、インデックス エラーを迅速に診断するのに役立ちます。 たとえば、互換性のないインデックス値の形式が見つかった場合は、すぐにエラーが返されます。
MongoDB 7.1 と比較して、インデックス構築エラーが返されるまでに長い時間がかかる可能性があります。このエラーはコミットフェーズのインデックス構築の終了間して返されるためです。
配置の回復力を強化。 インデックスビルドエラーが発生した場合、セカンダリノードはプライマリメンバーにインデックスビルドの停止をリクエストでき、セカンダリノードはクラッシュしません。 インデックスビルドを停止するリクエストは常に可能ではありません。ノードがすでにインデックスをコミットするために投票している場合、セカンダリはインデックスビルドの停止をリクエストできず、セカンダリはクラッシュします(MongoDB 7.0 以前と同様)。
インデックス構築エラーにより、セカンダリ ノードがクラッシュする可能性があります。
インデックス ビルドのためのディスク領域の管理を改善しました。 使用可能なディスク容量がindexBuildMinAvailableDiskSpaceMBパラメータで指定された最小値を下回ると、インデックスビルドが自動的に停止されることがあります。 ノードがすでにインデックスをコミットするために投票している場合、インデックスのビルドは停止されません。
使用可能なディスク容量が不足しても、インデックスの構築は停止しません。

Tip

以下も参照してください。

db.collection.createIndex() に、さまざまなインデックス仕様の例があります。

次のようなドキュメントを含む restaurants コレクションを考えてみましょう。

{
location: {
type: "Point",
coordinates: [-73.856077, 40.848447]
},
name: "Morris Park Bake Shop",
cuisine: "Cafe",
borough: "Bronx",
}

次の例では、restaurants コレクションに 2 つのインデックスを作成します。 1 つは borough フィールドの昇順インデックスで、もう 1 つは location フィールドの 2dsphere インデックスです。

db.restaurants.createIndexes([{"borough": 1}, {"location": "2dsphere"}])

次の例では、products コレクションに 2 つのインデックスを作成します。1 つは manufacturer フィールドの昇順インデックスで、もう 1 つは category フィールドの昇順インデックスです。どちらのインデックスも、ロケール fr と比較強度 2 を指定する照合を使用します。

db.products.createIndexes( [ { "manufacturer": 1}, { "category": 1 } ],
{ collation: { locale: "fr", strength: 2 } })

同じ照合ルールを使用するインデックス付きキーに対するクエリまたはソート操作では、MongoDB はインデックスを使用できます。詳細については、「照合とインデックスの使用」を参照してください。

ワイルドカード インデックスの詳細については、「ワイルドカード インデックス」を参照してください。

次に、ワイルドカード インデックスの作成例を示します。

ドキュメントに product_attributes フィールドが含まれる可能性があるコレクション products_catalog を考えてみましょう。product_attributes フィールドには、埋め込みドキュメントや配列など、任意のネストされたフィールドを含めることができます。

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" ]
}
}
] )

次の操作を実行すると、product_attributes フィールドでワイルドカード インデックスが作成されます。

use inventory
db.products_catalog.createIndexes(
[ { "product_attributes.$**" : 1 } ]
)

このワイルドカード インデックスを使用すると、MongoDB はproduct_attributes のすべてのスカラー値をインデックス化します。フィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。

ワイルドカード インデックスは、product_attributes またはそのネストされたフィールドに対する任意の単一フィールド クエリをサポート可能です。

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" } } )

注意

パス固有のワイルドカード インデックス構文はwildcardProjectionオプションと互換性がありません。 詳細については、パラメーターのドキュメントを参照してください。

ドキュメントに product_attributes フィールドが含まれる可能性があるコレクション products_catalog を考えてみましょう。product_attributes フィールドには、埋め込みドキュメントや配列など、任意のネストされたフィールドを含めることができます。

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" ]
}
}
] )

次の操作を実行すると、すべてのスカラー フィールド(_id フィールドを除く)にワイルドカード インデックスが作成されます。

use inventory
db.products_catalog.createIndexes( [ { "$**" : 1 } ] )

このワイルドカード インデックスを使用すると、MongoDB はコレクション内の各ドキュメントのすべてのスカラー フィールドにインデックスを作成します。特定のフィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。

作成されたインデックスは、コレクションのドキュメント内の任意のフィールドに対するクエリをサポートできます。

db.products_catalog.find( { "product_price" : { $lt : 25 } } )
db.products_catalog.find( { "product_attributes.elements" : { $eq: "water" } } )

注意

ワイルドカード インデックスでは、デフォルトで _id フィールドが省略されます。_id フィールドをワイルドカード インデックスに含めるには、wildcardProjection ドキュメントに明示的に含める必要があります。詳細については、パラメーターのドキュメントを参照してください。

ドキュメントに product_attributes フィールドが含まれる可能性があるコレクション products_catalog を考えてみましょう。product_attributes フィールドには、埋め込みドキュメントや配列など、任意のネストされたフィールドを含めることができます。

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" ]
}
}
] )

次の操作ではワイルドカード インデックスを作成し、wildcardProjection オプションを使用して product_attributes.elements および product_attributes.resistance フィールドのスカラー値のみをインデックスに含めます。

use inventory
db.products_catalog.createIndexes(
[ { "$**" : 1 } ],
{
"wildcardProjection" : {
"product_attributes.elements" : 1,
"product_attributes.resistance" : 1
}
}
)

パターン "$**" にはドキュメント内のすべてのフィールドが含まれます。指定されたフィールドにインデックスを制限するには、wildcardProjection フィールドを使用します。

wildcardProjection の完全なドキュメントについては、「wildcard インデックスのオプション」を参照してください。

フィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。

ワイルドカード インデックスは、wildcardProjection に含まれる任意のスカラーフィールドに対するクエリをサポートします。

db.products_catalog.find( { "product_attributes.elements" : { $eq: "Water" } } )
db.products_catalog.find( { "product_attributes.resistance" : "Bludgeoning" } )

注意

ワイルドカード インデックスは、_id フィールドを明示的に含める場合を除きwildcardProjection ドキュメントに包含・除外ステートメントを混在させることはできません。wildcardProjection の詳細については、パラメーターのドキュメントを参照してください。

ドキュメントに product_attributes フィールドが含まれる可能性があるコレクション products_catalog を考えてみましょう。product_attributes フィールドには、埋め込みドキュメントや配列など、任意のネストされたフィールドを含めることができます。

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" ]
}
}
] )

この例では、ワイルドカード インデックスと wildcardProjection ドキュメントを使用して、コレクション内の各ドキュメントのスカラー フィールドにインデックスを作成します。ワイルドカード インデックスでは、product_attributes.elements フィールドと product_attributes.resistance フィールドは除外されます。

use inventory
db.products_catalog.createIndexes(
[ { "$**" : 1 } ],
{
"wildcardProjection" : {
"product_attributes.elements" : 0,
"product_attributes.resistance" : 0
}
}
)

ワイルドカード パターン "$**" にはドキュメント内のすべてのフィールドが含まれます。ただし、wildcardProjection フィールドは指定されたフィールドをインデックスから除外します。

wildcardProjection の完全なドキュメントについては、「wildcard インデックスのオプション」を参照してください。

フィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。

インデックスは、wildcardProjection で除外されたフィールドを除く任意のスカラー フィールドに対するクエリをサポートできます。

db.products_catalog.find( { "product_attributes.maxSpeed" : { $gt: 25 } } )
db.products_catalog.find( { "product_attributes.superStrength" : true } )

注意

ワイルドカード インデックスは、_id フィールドを明示的に含める場合を除きwildcardProjection ドキュメントに包含・除外ステートメントを混在させることはできません。wildcardProjection の詳細については、パラメーターのドキュメントを参照してください。

注意

FeatureCompatibilityVersion 4.4 以上が必要です。

レプリカセット全体でインデックス構築を同時に開始するには、レプリカセットまたはシャーディングされたクラスター内の各 mongod は、featureCompatibilityVersion を少なくとも 4.4 に設定する必要があります

レプリカセットまたはシャーディングされたクラスター上のインデックスは、データを保持するすべてのレプリカセット ノードで同時に構築されます。シャーディングされたクラスターの場合、インデックス構築は、インデックスが作成されるコレクションのデータを含むシャードでのみ行われます。プライマリは、インデックスを使用可能とマークする前に、自身を含む最小限のデータを保持する voting ノード(コミットクォーラム)でインデックス構築を完了する必要があります。詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。

コミットクォーラムを設定するには、createIndexes() を使用して commitQuorum 値を指定します。

commitQuorum は、データを保持する投票ノードの数、またはプライマリがコミットを実行する前にプライマリを含めてどの投票ノードがインデックス構築のコミット準備をしておく必要があるかを指定します。コミットクォーラムのデフォルトである votingMembers は、データを保持するすべてのノードを指します。

次の操作では、コミットクォーラム"majority"のインデックスが作成されます。

db.getSiblingDB("examples").invoices.createIndexes(
{ "invoices" : 1 },
{ },
"majority"
)

プライマリがインデックス構築を準備完了とマークするには、データを保持する単純過半数の投票ノードがインデックス構築をコミットするために「投票」済みである必要があります。インデックス構築と投票プロセスの詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。

カリフォルニア州(CA)とワシントン州(WA)のケーキ販売を含む cakeSales コレクションを作成します。

db.cakeSales.insertMany( [
{ _id: 0, type: "chocolate", orderDate: new Date("2020-05-18T14:10:30Z"),
state: "CA", price: 13, quantity: 120 },
{ _id: 1, type: "chocolate", orderDate: new Date("2021-03-20T11:30:05Z"),
state: "WA", price: 14, quantity: 140 },
{ _id: 2, type: "vanilla", orderDate: new Date("2021-01-11T06:31:15Z"),
state: "CA", price: 12, quantity: 145 },
{ _id: 3, type: "vanilla", orderDate: new Date("2020-02-08T13:13:23Z"),
state: "WA", price: 13, quantity: 104 },
{ _id: 4, type: "strawberry", orderDate: new Date("2019-05-18T16:09:01Z"),
state: "CA", price: 41, quantity: 162 },
{ _id: 5, type: "strawberry", orderDate: new Date("2019-01-08T06:12:03Z"),
state: "WA", price: 43, quantity: 134 }
] )

次の例では、cakeSales コレクションに複数のインデックスを作成します。

db.cakeSales.createIndexes( [
{ "type": 1 },
{ "orderDate": 1 },
{ "state": 1 },
{ "orderDate": 1, "state": -1 }
] )

最初の 3 つのインデックスは単一のフィールドにあり、昇順(1)です。

最後のインデックスは、orderDate では昇順(1)で、state では降順(-1)です。

インデックスに関する追加情報については、以下を参照してください。

戻る

db.collection.createIndex