クエリプランとクエリプランの実行統計に関する情報を返すために、MongoDB では次のメソッドが用意されています。
重要な Explain プラン フィールドとその解釈方法については、「Explain プラン 結果の解釈」を参照してください。
重要
explain はプラン キャッシュを無視します。その代わりに、候補プランのセットが生成され、プラン キャッシュをコンサルティングすることなく勝者が選ばれます。さらに、explain は MongoDB クエリ プランナーが当選プランをキャッシュするのを防ぎます。
注意
このページには最も重要な出力フィールドのみが表示され、内部使用のフィールドについては文書化されていません。出力に記載されているフィールドは変更される場合があります。
出力構造の説明
explain の結果は、クエリプランがステージのツリーとして表示されます。出力構造は、操作で使用されるクエリ エンジンによって異なる場合があります。操作には、クラシック クエリ エンジンまたはスロットベースの実行クエリ エンジンを使用できます。
2 つの実行エンジン間で出力構造がどのように異なるかを確認するには、次の例を参照してください。
winningPlan: { stage: <STAGE1>, ... inputStage: { stage: <STAGE2>, ... inputStage: { stage: <STAGE3>, ... } } },
winningPlan: { queryPlan: { stage: <STAGE1>, ... inputStage: { stage: <STAGE2>, ... inputStage: { stage: <STAGE3>, ... } } } slotBasedPlan: { ... } },
各ステージでは、結果のドキュメントまたはインデックス キーが親ノードに渡されます。リーフ ノードはコレクションまたはインデックスにアクセスします。内部ノードは、子ノードから生成されたドキュメントまたはインデックス キーを使用します。ルート ノードは、MongoDB が最終的に結果セットを導き出すステージを表します。
ステージは、操作について説明しています。例は次のとおりです。
COLLSCAN、コレクションスキャン用IXSCAN、インデックス キーのスキャン用FETCH、ドキュメント検索用GROUP、ドキュメントのグループ化用SHARD_MERGEシャードからの結果のマージ用SHARDING_FILTER、シャードから孤立したドキュメントのフィルタリング用TS_MODIFYは、時系列コレクションの変更BATCHED_DELETE複数のドキュメントを内部的に一括削除する場合(MongoDB 6.1 以降)EXPRESSは、最適化されたインデックススキャンプランを使用するために、通常のクエリプランをバイパスすることができる限られたクエリのセットのためのステージです(バージョン 8.0 の新機能)。EXPRESSステージは次のいずれかになります。EXPRESS_CLUSTERED_IXSCANEXPRESS_DELETEEXPRESS_IXSCANEXPRESS_UPDATE
MongoDB 5.1 以降の explain 出力
このセクションで示されているのは、MongoDB 5.1 以降の explain 出力です。MongoDB 5.1 より前のバージョンの explain 出力を確認するには、該当バージョンのドキュメントを参照してください。
queryPlanner
explain.queryPlanner 情報には、クエリオプティマイザによって選択されたプランの詳細が示されます。
これらの例では、MongoDB のクラシック実行エンジンとスロットベースの実行エンジンの出力構造を組み合わせることができます。どちらも典型的という意図はありません。出力が著しく異なる場合があります。
シャーディングされていないコレクションの場合、explain は次の queryPlanner 情報を返します。
queryPlanner: { namespace: <string>, indexFilterSet: <boolean>, parsedQuery: { ... }, planCacheShapeHash: <hexadecimal string>, planCacheKey: <hexadecimal string>, maxIndexedOrSolutionsReached: <boolean>, maxIndexedAndSolutionsReached: <boolean>, maxScansToExplodeReached: <boolean>, winningPlan: { stage: <STAGE1>, inputStage: { stage: <string>, ... } }, rejectedPlans: [ <candidate plan1>, ] }
MongoDB 8.0 以降では、既存の queryHashフィールドはplanCacheShapeHash という名前の新しいフィールドに重複します。 以前のバージョンのMongoDBを使用している場合は、queryHashフィールドのみが表示されます。 今後のMongoDBバージョンでは、非推奨の queryHashフィールドが排除されます。代わりに planCacheShapeHashフィールドを使用する必要があります。
シャーディングされたコレクションの場合、explain には shards フィールドの各アクセスされたシャード向けの主要クエリ プランナーとサーバーに関する情報が含まれます。
{ queryPlanner: { mongosPlannerVersion: <int> winningPlan: { stage: <STAGE1>, shards: [ { shardName: <string>, connectionString: <string>, serverInfo: { ... }, namespace: <string>, indexFilterSet: <boolean>, parsedQuery: { ... }, querySettings: { ... }, planCacheShapeHash: <hexadecimal string>, planCacheKey: <hexadecimal string>, maxIndexedOrSolutionsReached: <boolean>, maxIndexedAndSolutionsReached: <boolean>, maxScansToExplodeReached: <boolean>, winningPlan: { stage: <STAGE1>, inputStage: { stage: <string>, ... } }, rejectedPlans: [ <candidate plan1>, ] } ] } } }
MongoDB 8.0 以降では、既存の queryHashフィールドはplanCacheShapeHash という名前の新しいフィールドに重複します。 以前のバージョンのMongoDBを使用している場合は、queryHashフィールドのみが表示されます。 今後のMongoDBバージョンでは、非推奨の queryHashフィールドが排除されます。代わりに planCacheShapeHashフィールドを使用する必要があります。
explain.queryPlannerクエリオプティマイザによるクエリプランの選択に関する情報が含まれています。
explain.queryPlanner.namespaceクエリによってアクセスされるデータベースとコレクションの名前を含む名前空間を指定する文字列です。名前空間の形式は
<database>.<collection>です。
explain.queryPlanner.indexFilterSetMongoDB でプランキャッシュクエリシェイプにインデックス フィルターが適用されたかどうかを指定するブール値。
explain.queryPlanner.querySettingsクエリ設定が設定されている場合、
querySettingsにはクエリシェイプに適用されるクエリ設定の詳細が含まれます。クエリ設定を追加し、
querySettingsでのexplain()出力を含む例を確認するには、setQuerySettingsを参照してください。バージョン8.0の新機能。
explain.queryPlanner.planCacheShapeHashMongoDB 8.0 以降では、既存の
queryHashフィールドはplanCacheShapeHashという名前の新しいフィールドに重複します。 以前のバージョンのMongoDBを使用している場合は、queryHashフィールドのみが表示されます。 今後のMongoDBバージョンでは、非推奨のqueryHashフィールドが排除されます。代わりにplanCacheShapeHashフィールドを使用する必要があります。プランキャッシュクエリシェイプのハッシュを表す16進数文字列で、プランキャッシュクエリシェイプにのみ依存します。
planCacheShapeHashは、同じプランキャッシュクエリシェイプを持つ遅いクエリ(書き込み操作のクエリフィルタを含む)を識別するのに役立ちます。注意
他のハッシュ関数と同様に、2 つの異なるプランキャッシュクエリシェイプで同じハッシュ値が生成される場合があります。ただし、異なるプランキャッシュクエリシェイプ間でハッシュ衝突が発生する可能性は低くなります。
planCacheShapeHashとplanCacheKeyの詳細については、planCacheShapeHash と planCacheKey を参照してください。
explain.queryPlanner.planCacheKeyクエリに関連付けられたプラン キャッシュ エントリのキーのハッシュです。
explain.queryPlanner.planCacheShapeHashとは異なり、explain.queryPlanner.planCacheKeyは、プランキャッシュクエリシェイプとそのシェイプで現在使用可能なインデックスの両方の関数です。具体的には、クエリシェイプをサポートできるインデックスを追加または削除すると、planCacheKeyの値は変わりますがplanCacheShapeHashの値は変わりません。planCacheShapeHashとplanCacheKeyの詳細については、planCacheShapeHash と planCacheKey を参照してください。
explain.queryPlanner.optimizationTimeMillisクエリ プランナーがクエリの最適化に費やした時間(ミリ秒)。この結果には、内部
$lookupクエリの最適化に費やされた時間は含まれません。
explain.queryPlanner.optimizedPipeline集計パイプライン操作全体が最適化され、クエリプランの実行ステージをツリー形式に体系化して実行されるようになったことを示すブール値。
たとえば、次の集計操作は集計パイプラインを使用するのではなく、クエリプラン実行のツリーで実行できます。
db.example.aggregate([ { $match: { someFlag: true } } ] ) このフィールドは、値が
trueの場合にのみ表示され、集計パイプライン操作を説明する目的でのみ適用されます。値をtrueに設定すると、パイプラインが最適化されたため、集計ステージ情報は出力に表示されません。
explain.queryPlanner.winningPlanクエリオプティマイザによって選択されたプランの詳細が記載されたドキュメントです。
explain.queryPlanner.winningPlan.stageステージ名を示す文字列。
各ステージは、ステージに固有の情報で構成されます。たとえば、
IXSCANステージには、インデックスの限界と、インデックス スキャンに固有の他のデータが含まれます。ステージに子ステージが 1 つまたは複数ある場合、そのステージにはinputStageまたはinputStagesが含まれます。このフィールドは、操作でクラシック クエリ実行エンジンが使用された場合に表示されます。
explain.queryPlanner.winningPlan.inputStage子ステージを記述するドキュメントで、ドキュメントまたはインデックス キーを親に提供します。このフィールドは、親ステージに子ステージが 1 つのみという条件を満たす場合に表示されます。
explain.queryPlanner.winningPlan.inputStages子ステージを説明するドキュメントの配列。 子ステージは、親ステージにドキュメントまたはインデックス キーを提供します。 このフィールドは、親ステージに複数の子ノードがある場合に表示されます。 たとえば、 $or 式の ステージは複数のソースからの入力を消費する可能性があります。
このフィールドは、操作でクラシック クエリ実行エンジンが使用された場合に表示されます。
explain.queryPlanner.winningPlan.isCachedwinPlan がプラン キャッシュにあるかどうかを示すブール値。
このフィールドは、当選プランと拒否されたプランの間に最大 1 つのプランがある場合、
trueです。 クエリにキャッシュされたプランがない場合、このフィールドは当選したプランと拒否されたプランのfalseになります。
explain.queryPlanner.winningPlan.queryPlanクエリオプティマイザによって選択されたプランの詳細が記載されたドキュメントです。MongoDB では、プランはステージのツリーとして表示されます。
このドキュメントは、クエリがスロットベースの実行クエリエンジンを使用した場合に表示されます。
バージョン 5.1 で追加。
explain.queryPlanner.winningPlan.queryPlan.stageステージ名を示す文字列。
各ステージは、ステージに固有の情報で構成されます。たとえば、
IXSCANステージには、インデックスの限界と、インデックス スキャンに固有の他のデータが含まれます。
explain.queryPlanner.winningPlan.queryPlan.planNodeId実行プランの各ステージを識別するユニークな整数フィールドで、
explain結果全体をカバーするすべてのステージに含まれます。バージョン 5.1 で追加。
explain.queryPlanner.winningPlan.queryPlan.inputStage「
explain.queryPlanner.winningPlan.inputStage」を参照してください。
explain.queryPlanner.winningPlan.slotBasedPlanスロットベースのクエリ実行プランのツリーとステージに関する情報が記載されたドキュメント。MongoDB の内部使用ドキュメントです。
バージョン 5.1 で追加。
explain.queryPlanner.winningPlan.slotBasedPlan.stages実行順序、操作、スロット割り当てなど、スロットベースのクエリ実行プランの各ステージに関する情報を含むstring。MongoDB の内部使用ドキュメントです。
MongoDB 8.0 以降では、クエリでブロック処理が使用される場合、
block_to_rowとts_bucket_to_cellblockはstages出力に表示されます。バージョン8.0で変更。
explain.queryPlanner.rejectedPlansクエリオプティマイザによって検討および拒否された候補プランの配列です。他に候補プランがなければ、配列は空にできます。
拒否されたプランには
explain.queryPlanner.winningPlanと同じフィールドが含まれます。MongoDB 8.0以降、拒否されたクエリプランにはクエリの
find部分のみが含まれます。 以前のバージョンでは、拒否されたプランには$groupのような 集計ステージ が含まれることがあります。 これらの集計ステージは勝利プランを選択するためにクエリ プランナーによって使用されることはありません。そのため、rejectedPlansフィールドには、勝利プランを選択するために使用されたクエリの部分のみが含まれます。
executionStats
返されたexplain.executionStats情報には、当選プランの実行の詳細が表示されます。 結果にexecutionStatsを含めるには、次のいずれかで explain を実行する必要があります。
allPlansExecution の冗長モードです。プラン選択中にキャプチャされた部分的な実行データを含めるには、
allPlansExecutionモードを使用します。
これらの例では、MongoDB のクラシック実行エンジンとスロットベースの実行エンジンの出力構造を組み合わせることができます。どちらも典型的という意図はありません。出力が著しく異なる場合があります。
シャーディングされていないコレクションの場合、explain は次の executionStats 情報を返します。
executionStats: { executionSuccess: <boolean>, nReturned: <int>, executionTimeMillis: <int>, totalKeysExamined: <int>, totalDocsExamined: <int>, executionStages: { stage: <STAGE1> nReturned: <int>, executionTimeMillisEstimate: <int>, opens: <int>, // Starting in MongoDB 5.1 closes: <int>, // Starting in MongoDB 5.1 works: <int>, advanced: <int>, needTime: <int>, needYield: <int>, saveState: <int>, restoreState: <int>, isEOF: <boolean>, ... inputStage: { stage: <STAGE2>, nReturned: <int>, ... numReads: <int>, // Starting in MongoDB 5.1 ... executionTimeMillisEstimate: <int>, ... inputStage: { ... } } }, allPlansExecution: [ { nReturned: <int>, executionTimeMillisEstimate: <int>, totalKeysExamined: <int>, totalDocsExamined:<int>, executionStages: { stage: <STAGEA>, nReturned: <int>, executionTimeMillisEstimate: <int>, ... inputStage: { stage: <STAGEB>, ... inputStage: { ... } } } }, ... ] operationMetrics: { cpuNanos: <int>, cursorSeeks: <int>, docBytesRead: <int>, docBytesWritten: <int>, docUnitsRead: <int>, docUnitsReturned: <int>, docUnitsWritten: <int>, idxEntryBytesRead: <int>, idxEntryBytesWritten: <int>, idxEntryUnitsRead: <int>, idxEntryUnitsWritten: <int>, totalUnitsWritten: <int>, keysSorted: <int>, sorterSpills: <int> } }
シャーディングされたコレクションの場合、 explainにはアクセスされた各シャードの実行統計が含まれます。
executionStats: { nReturned: <int>, executionTimeMillis: <int>, totalKeysExamined: <int>, totalDocsExamined: <int>, executionStages: { stage: <STAGE1> nReturned: <int>, executionTimeMillis: <int>, opens: <int>, // Starting in MongoDB 5.1 closes: <int>, // Starting in MongoDB 5.1 totalKeysExamined: <int>, totalDocsExamined: <int>, totalChildMillis: <NumberLong>, shards: [ { shardName: <string>, executionSuccess: <boolean>, executionStages: { stage: <STAGE2>, nReturned: <int>, executionTimeMillisEstimate: <int>, ... chunkSkips: <int>, inputStage: { stage: <STAGE3>, ... numReads: <int>, // Starting in MongoDB 5.1 ... inputStage: { ... } } } }, ... ] } allPlansExecution: [ { shardName: <string>, allPlans: [ { nReturned: <int>, executionTimeMillisEstimate: <int>, totalKeysExamined: <int>, totalDocsExamined:<int>, executionStages: { stage: <STAGEA>, nReturned: <int>, executionTimeMillisEstimate: <int>, ... inputStage: { stage: <STAGEB>, ... inputStage: { ... } } } }, ... ] }, { shardName: <string>, allPlans: [ ... ] }, ... ] }
explain.executionStats当選プランの完了したクエリ実行を示す統計が含まれます。書込み (write) 操作の場合、完了したクエリの実行とは、実行される予定の変更を指しますが、変更はデータベースに適用されません。
explain.executionStats.nReturned当選したクエリプランが返したドキュメントの数。
nReturnedは、MongoDB の以前のバージョンでcursor.explain()によって返されたnフィールドに対応しています。
explain.executionStats.executionTimeMillisクエリプランの選択とクエリの実行に必要な合計時間(ミリ秒)。これには、プラン選択プロセスの試用段階を実行する時間は含まれるが、データをクライアントに送り返すためのネットワーク時間は含まれません。
explain.executionStats.executionTimeMillisによって報告される時間は、必ずしも実際のクエリ時間を表していません。定常状態の操作中(クエリプランがキャッシュされている場合)、またはcursor.hint()をcursor.explain()とともに使用している場合、MongoDB はプラン選択プロセスをバイパスし、実際の時間が短縮されてexplain.executionStats.executionTimeMillis値が低くなります。
explain.executionStats.totalKeysExaminedスキャンされたインデックスエントリの数。
explain.executionStats.totalKeysExaminedは、MongoDB の以前のバージョンでcursor.explain()によって返されたnscannedフィールドに対応しています。
explain.executionStats.totalDocsExaminedクエリの実行中に検査されたドキュメントの数。ドキュメントを検査する一般的なクエリ実行ステージは、
COLLSCANとFETCHです。注意
explain.executionStats.totalDocsExaminedは、返されたドキュメント数ではなく、検査されたドキュメントの合計数を示します。たとえば、ステージではフィルターを適用するためにドキュメントを調べることができます。ドキュメントがフィルターで除外された場合、そのドキュメントは検査済みですが、クエリ結果セットの一部として返されません。クエリの実行中にドキュメントが複数回検査された場合、
explain.executionStats.totalDocsExaminedはそれぞれの検査でカウントします。 つまり、explain.executionStats.totalDocsExaminedは検査された一意のドキュメントの合計数ではありません。
explain.executionStats.executionStages当選プランの実行が完了したことをステージのツリーとして表示します。つまり、1 つのステージに 1 つの
inputStageまたは複数のinputStagesがあってもかまいません。MongoDB 5.1 以降では、次の入力ステージをステージに含めることができます。
thenStageelseStageinnerStageouterStage
各ステージは、ステージに固有の実行情報で構成されます。
explain.executionStats.executionStages.worksクエリ実行ステージで実行される「ワーク ユニット」の数を指定します。クエリの実行では、作業が小さな単位に分割されます。「ワークユニット」には、1 つのインデックス キーの調査、コレクションから 1 つのドキュメントの取り出し、1 つのドキュメントにプロジェクションを適用、あるいは、内部ブックキーピングの実行で構成される場合があります。
このフィールドは、操作でクラシック クエリ実行エンジンが使用された場合に表示されます。
explain.executionStats.executionStages.restoreStateクエリ ステージが保存された実行状態を復元した回数です。たとえば、以前に生成したロックをリカバリした後です。
explain.executionStats.executionStages.isEOF実行ステージがストリームの終わりに達したかどうかを次のとおり指定します。
trueまたは1の場合、実行ステージはストリームの終端に達しています。falseまたは0の場合、ステージにまだ返される結果がある可能性があります。たとえば、制限のあるクエリで、実行ステージを構成するLIMITステージに、IXSCANとクエリ用に入力するステージがあるものを考えてみましょう。このクエリから指定した制限を超える値が返される場合、LIMITステージではisEOF: 1と報告されますが、その基礎となるIXSCANステージではisEOF: 0と報告されます。
explain.executionStats.executionStages.bucketFilter時系列コレクションに対する操作の場合、バケット カタログでクエリされるバケットの数を絞るために使用されるフィルター。
explain.executionStats.executionStages.residualFilter時系列コレクションに対する操作の場合、バケット カタログをクエリするために使用されるフィルター。
explain.executionStats.executionStages.inputStage各
inputStageのフィールドは、inputStage.stageの値に応じて異なる可能性があります。次の表では、使用可能なフィールドとフィールドが表示される可能性のあるステージについて説明しています。各
inputStageには、別のinputStageをフィールドとして含めることができます。 出力構造の説明 を参照してください。フィールド説明適用可能なステージdocsExaminedクエリ実行ステージでスキャンされるドキュメントの数を指定します。
COLLSCAN,FETCHkeysExaminedインデックスをスキャンするクエリ実行ステージの場合、
keysExaminedはインデックス スキャンのプロセスで検査される限界内のキーと限界外のキーの総数。インデックス スキャンが 1 つの連続したキー範囲で構成されている場合は、範囲内のキーのみを調べる必要があります。インデックスの限界が複数のキー範囲で構成されている場合、インデックス スキャンの実行プロセスでは、ある範囲の終わりから次の範囲の先頭にスキップするために、範囲外のキーを調べることがあります。IXSCANnumReadsクエリ実行段階でスキャンされたドキュメントの数、または検査されたインデックス キーの数。
バージョン 5.1 で追加。
COLLSCAN,IXSCANseeksインデックス カーソルがインデックス スキャンを完了するための新しい位置を探すのに必要だった回数。
IXSCANspilledBytesApproxステージ内でディスクにスピルしたインメモリのバイト数の概算。
バージョン 5.3 で追加。
GROUPspilledRecordsステージ内でディスクにスピルした、生成されたレコードの数。
バージョン 5.3 で追加。
GROUPusedDiskステージでディスクに書込み (write) されたかどうか。
バージョン 5.3 で追加。
GROUP
explain.executionStats.allPlansExecution当選したプランと拒否されたプランの両方について、プラン選択フェーズ中にキャプチャされた部分的な実行情報が含まれます。このフィールドは、
explainがallPlansExecution冗長モードで実行されている場合にのみ存在します。
explain.executionStats.operationMetricsリソース消費統計が含まれます(0 の場合を除く)。このフィールドが表示されるのは、
explainがexecutionStats冗長モード以上で実行され、かつprofileOperationResourceConsumptionMetricsが有効な場合のみです。
serverInfo
シャーディングされていないコレクションの場合、explain は MongoDB インスタンスの次の serverInfo 情報を返します。
serverInfo: { host: <string>, port: <int>, version: <string>, gitVersion: <string> }
シャーディングされたコレクションの場合、 explainはアクセスしたシャードごとにserverInfoを返し、 mongos の最上位のserverInfoオブジェクトを返します
queryPlanner: { ... winningPlan: { stage: <STAGE1>, shards: [ { shardName: <string>, connectionString: <string>, serverInfo: { host: <string>, port: <int>, version: <string>, gitVersion: <string> }, ... } ... ] } }, serverInfo: { // serverInfo for mongos host: <string>, port: <int>, version: <string>, gitVersion: <string> } ...
パイプライン ステージを使用するクエリの実行プラン統計$lookup
バージョン 5.0 で追加
explain の結果には、$lookup のパイプライン ステージを使用するクエリの実行統計を含めることができます。これらの実行統計を含めるには、以下のいずれかの実行冗長モードで説明操作を実行する必要があります。
$lookup クエリの explain の結果には次のフィールドが含まれます。
'$lookup': { from: <string>, as: <string>, localField: <string>, foreignField: <string> }, totalDocsExamined: <long>, totalKeysExamined: <long>, collectionScans: <long>, indexesUsed: [ <string_1>, <string_2>, ..., <string_n> ], executionTimeMillisEstimate: <long>
$lookup セクションのフィールドの説明については、$lookup ページを参照してください。
その他のフィールドは次のとおりです。
コレクションスキャン
クエリ プランナーがコレクションスキャンを選択した場合、explain の結果には COLLSCAN ステージが含まれます。
クエリ プランナーによってインデックスが選択された場合、explain の結果には IXSCAN ステージが加わります。このステージでは、インデックス キーのパターン、トラバースの方向、インデックスの限界などの情報が提供されます。
MongoDB 5.3 以降では、クエリ プランナーでクラスター化されたコレクションにクラスター化されたインデックスが選択され、かつ検索するインデックス部分を定義する限界がクエリに含まれている場合、explain の結果には CLUSTERED_IXSCAN ステージが加わります。このステージでは、クラスター化されたインデックスキーとインデックスの限界に関する情報が提供されます。
クエリ プランナーによってクラスター化されたコレクションにクラスター化されたインデックスが選択され、かつクエリに限界が含まれていない場合、クエリでは、限界抜きでコレクションのスキャンが実行され、explain の結果には COLLSCAN ステージが加わります。
注意
限界が設定されていないクエリで、クラスター化インデックスを使用するものは、コレクションのフル スキャンが必要なため、notablescan パラメーターでは許可されません。
コレクションスキャンの実行統計の詳細については、Explain プラン 結果の解釈を参照してください。
カバード クエリ
インデックスがクエリをカバーする場合、MongoDB ではクエリの条件を一致させること、およびインデックスキーのみを使用して結果を返すこともできます。MongoDBでは、クエリの一部を実行するためにコレクションのドキュメントを検査する必要はありません。
インデックスがクエリを補う場合、explain の結果には FETCH ステージの子孫ではない、IXSCAN ステージがあり、executionStats では explain.executionStats.totalDocsExamined は 0 です。
$or 式
MongoDB が $or 式にインデックスを使用する場合、結果にはインデックスの詳細を示す explain.queryPlanner.winningPlan.inputStages 配列を含む、OR ステージが含まれます。以下がその例です。
{ stage: 'OR', inputStages: [ { stage: 'IXSCAN', ... }, { stage : 'IXSCAN', ... }, ... ] }
MongoDB の以前のバージョンでは、cursor.explain() インデックスの詳細を示す clauses 配列を返していました。
$sort ステージと$group ステージ
explain が、executionStats または allPlansExecution 冗長モードのいずれかで実行されると、$sort および $group ステージに追加の出力があります。
ステージ | フィールド | タイプ | 説明 |
|---|---|---|---|
| long |
| |
| ブール値 |
| |
| long |
| |
| ブール値 |
| |
| long |
| |
| long | 圧縮前の |
ソート ステージ
MongoDB がインデックスつまたは複数のインデックスを使用してソート順序を取得できない場合、結果には メモリ内ソート操作 を示す SORT ステージが含まれます。explain プランに明示的な SORT ステージが含まれていない場合、 MongoDB はインデックスを使用して並べ替え順を取得しました。
クエリシェイプハッシュ
MongoDB 8.0 以降、explain は次のフィールドを出力します。