explain の結果

queryPlanner

explain.queryPlanner 情報には、クエリオプティマイザによって選択されたプランの詳細が示されます。

これらの例では、クラシック実行エンジンとスロットベースの実行エンジンの出力構造を組み合わせることができます。どちらも典型的という意図はありません。出力が著しく異なる場合があります。

queryPlanner: {   namespace: <string>,   indexFilterSet: <boolean>,   parsedQuery: {      ...   },   planCacheShapeHash: <hexadecimal string>,   planCacheKey: <hexadecimal string>,   maxIndexedOrSolutionsReached: <boolean>,   maxIndexedAndSolutionsReached: <boolean>,   maxScansToExplodeReached: <boolean>,   winningPlan: {     stage: <STAGE1>,     type: <string>,     inputStage: {       stage: <string>,       ...     }   },   rejectedPlans: [     <candidate plan1>,   ]}

{   queryPlanner: {      mongosPlannerVersion: <int>      winningPlan: {         stage: <STAGE1>,         type: <string>,         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>,               type: <string>,               inputStage: {                  stage: <string>,                  ...               }            },            rejectedPlans: [              <candidate plan1>,            ]         }         ]      }   }}

{   queryPlanner: {      mongosPlannerVersion: <int>      winningPlan: {         isCached: <boolean>,         stage: <STAGE1>,         costEstimate: <float>,         cardinalityEstimate: <float>,         estimatesMetadata: { ceSource: '<string>' },         inputStage: {           stage: <STAGE1>,           costEstimate: <float>,           cardinalityEstimate: <float>,           filterNumKeysEstimate: <float>,           numKeysEstimate: <float>,           estimatesMetadata: { ceSource: '<string>'} ,           ...         }      }   }}

explain.queryPlanner

クエリオプティマイザによるクエリプランの選択に関する情報が含まれています。

explain.queryPlanner.namespace

クエリによってアクセスされるデータベースとコレクションの名前を含む名前空間を指定する文字列です。名前空間の形式は <database>.<collection> です。

explain.queryPlanner.indexFilterSet

MongoDB でプランキャッシュクエリシェイプにインデックス フィルターが適用されたかどうかを指定するブール値。

explain.queryPlanner.querySettings

クエリ設定が設定されている場合、querySettings にはクエリシェイプに適用されるクエリ設定の詳細が含まれます。

クエリ設定を追加し、querySettings での explain() 出力を含む例を確認するには、setQuerySettings を参照してください。

バージョン8.0の新機能。

explain.queryPlanner.planCacheShapeHash

MongoDB 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.type

stage が "EOF" に設定されている場合、type は EOF ステージの理由を示す string です。

• "nonExistentNamespace": は、クエリ名前空間が存在しないことを示します。

• "predicateEvalsToFalse": は、式の単純化 によりクエリがどのドキュメントにも一致しないと判断されることを示します。

explain.queryPlanner.winningPlan.inputStage

子ステージを記述するドキュメントで、ドキュメントまたはインデックス キーを親に提供します。このフィールドは、親ステージに子ステージが 1 つのみという条件を満たす場合に表示されます。

explain.queryPlanner.winningPlan.inputStages

子ステージを説明するドキュメントの配列。 子ステージは、親ステージにドキュメントまたはインデックス キーを提供します。 このフィールドは、親ステージに複数の子ノードがある場合に表示されます。 たとえば、 $or 式の ステージは複数のソースからの入力を消費する可能性があります。

このフィールドは、操作でクラシック クエリ実行エンジンが使用された場合に表示されます。

explain.queryPlanner.winningPlan.isCached

winPlan がプラン キャッシュにあるかどうかを示すブール値。

このフィールドは、当選プランと拒否されたプランの間に最大 1 つのプランがある場合、 trueです。 クエリにキャッシュされたプランがない場合、このフィールドは当選したプランと拒否されたプランのfalseになります。

explain.queryPlanner.winningPlan.costEstimate

コストベースのランカーを各ステージで実行するために使用される概算の抽象コスト単位を表す float。コストベースのランカーは、最上位の costEstimate が最も低いプランを選択します。

バージョン8.3.3の新機能。

explain.queryPlanner.winningPlan.cardinalityEstimate

コストベースランカーのステージによって生成されるドキュメントまたはキーの推定数を表す浮動小数点。

バージョン8.3.3の新機能。

explain.queryPlanner.winningPlan.numKeysEstimate

クエリ プランナーがプランの処理を予測するインデックス キーの概算数を表すフロート。

numKeysEstimate と costEstimate の間の重大な違いは、winningPlan に関する問題を示す可能性があります。

バージョン8.3.3の新機能。

explain.queryPlanner.winningPlan.numDocsEstimate

スキャンされたドキュメントの概算数を表す浮動小数。

バージョン8.3.3の新機能。

explain.queryPlanner.winningPlan.estimatesMetadata

見積りがどのように導き出されたかに関するメタデータが含まれています。

バージョン8.3.3の新機能。

explain.queryPlanner.winningPlan.estimatesMetadata.ceSource

このステージで使用される濃度推定方法 (CE)。可能な浮動値は次のとおりです。

• sampling: MongoDB は、ベース コレクションのサンプルについて推定を計算します。

• heuristics: ルールのセットを使用して選択性を決定します。サンプリングが失敗した場合にのみ使用されます。

• mixed: 推定は、異なるタイプの推定を混合したいくつかの計算の結果です。

• metadata: 見積もりは、コレクションの濃度などのデータベース メタデータから得られます。

• code: C++ は、推定値を直接計算します。インスタンス、 定数や式です。

バージョン8.3.3の新機能。

explain.queryPlanner.winningPlan.queryPlan

クエリオプティマイザによって選択されたプランの詳細が記載されたドキュメントです。MongoDB では、プランはステージのツリーとして表示されます。

このドキュメントは、クエリがスロットベースの実行クエリエンジンを使用した場合に表示されます。

バージョン5.1の新機能。

explain.queryPlanner.winningPlan.queryPlan.stage

ステージ名を示す文字列。

各ステージは、ステージに固有の情報で構成されます。たとえば、IXSCAN ステージには、インデックスの限界と、インデックス スキャンに固有の他のデータが含まれます。

explain.queryPlanner.winningPlan.queryPlan.type

stage が "EOF" に設定されている場合、type は EOF ステージの理由を示す string です。

• "nonExistentNamespace": は、クエリ名前空間が存在しないことを示します。

• "predicateEvalsToFalse": は、式の単純化 によりクエリがどのドキュメントにも一致しないと判断されることを示します。

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 を実行する必要があります。

• executionStats

• allPlansExecution の冗長モードです。プラン選択中にキャプチャされた部分的な実行データを含めるには、allPlansExecution モードを使用します。

これらの例では、クラシック実行エンジンとスロットベースの実行エンジンの出力構造を組み合わせることができます。どちらも典型的という意図はありません。出力が著しく異なる場合があります。

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>,         ...         spills: <long long>,         spilledBytes: <long long>,         spilledRecords: <long long>,         spilledDataStorageSize: <long long>,         peakTrackedMemBytes: <long>, // Starting in 8.3         ...         inputStage: {            ...         }      }   },   allPlansExecution: [      {         nReturned: <int>,         executionTimeMillisEstimate: <int>,         totalKeysExamined: <int>,         totalDocsExamined: <int>,         score: <double>,         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>   }},...peakTrackedMemBytes: <long>, // Starting in 8.3...

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                  ...                  spills: <long long>,                  spilledBytes: <long long>,                  spilledRecords: <long long>,                  spilledDataStorageSize: <long long>,                  peakTrackedMemBytes: <long>, // Starting in 8.3                  ...                  inputStage: {                     ...                  }               }            }         },         ...      ]   }   allPlansExecution: [      {         shardName: <string>,         allPlans: [            {               nReturned: <int>,               executionTimeMillisEstimate: <int>,               peakTrackedMemBytes: <long>, // Starting in 8.3               totalKeysExamined: <int>,               totalDocsExamined:<int>,               executionStages: {                  stage: <STAGEA>,                  nReturned: <int>,                  executionTimeMillisEstimate: <int>,                  ...                  inputStage: {                     stage: <STAGEB>,                     ...                     inputStage: {                       ...                     }                  }               }            },            ...         ]      },      {         shardName: <string>,         allPlans: [          ...         ]      },      ...   ],   peakTrackedMemBytes: <long>, // Starting in 8.3   ...}

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.peakTrackedMemBytes

バージョン8.3の新機能。

現在の クエリ操作で使用されている追跡メモリの最大バイト数。

explain の実行統計により、クエリ全体と各ブロッキング ステージのピーク メモリが提供されます。ブロッキング ステージが 1 つだけの場合、クエリとステージ peakTrackedMemBytes の値は同じになります。

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.score

マルチプランナーによって選択された勝利プランのスコアを表す double 値。

バージョン8.3.3の新機能。

explain.executionStats.executionStages

当選プランの実行が完了したことをステージのツリーとして表示します。つまり、1 つのステージに 1 つの inputStage または複数の inputStages があってもかまいません。

MongoDB 5.1 以降では、次の入力ステージをステージに含めることができます。

• thenStage

• elseStage

• innerStage

• outerStage

各ステージは、ステージに固有の実行情報で構成されます。

explain.executionStats.executionStages.executionTimeMillisEstimate

クエリ実行の推定時間（ミリ秒単位）。

explain.executionStats.executionStages.opens

MongoDB 5.1 以降では、クエリの実行中にステージが開かれた回数を表します。

explain.executionStats.executionStages.closes

MongoDB 5.1 以降では、クエリ実行中にステージが閉じられた回数を表します。

explain.executionStats.executionStages.works

クエリ実行ステージで実行される「ワーク ユニット」の数を指定します。クエリの実行では、作業が小さな単位に分割されます。「ワークユニット」には、1 つのインデックス キーの調査、コレクションから 1 つのドキュメントの取り出し、1 つのドキュメントにプロジェクションを適用、あるいは、内部ブックキーピングの実行で構成される場合があります。

このフィールドは、操作でクラシック クエリ実行エンジンが使用された場合に表示されます。

explain.executionStats.executionStages.saveState

クエリ ステージで処理が中断され、現在の実行状態（ロックを解除する準備など）が保存された回数。

explain.executionStats.executionStages.restoreState

クエリ ステージが保存された実行状態を復元した回数です。たとえば、以前に生成したロックをリカバリした後です。

explain.executionStats.executionStages.isEOF

実行ステージがストリームの終わりに達したかどうかを次のとおり指定します。

• true または 1 の場合、実行ステージはストリームの終端に達しています。

• false または 0 の場合、ステージにまだ返される結果がある可能性があります。たとえば、制限のあるクエリで、実行ステージを構成するLIMIT ステージに、IXSCAN とクエリ用に入力するステージがあるものを考えてみましょう。このクエリから指定した制限を超える値が返される場合、LIMIT ステージでは isEOF: 1 と報告されますが、その基礎となる IXSCAN ステージでは isEOF: 0 と報告されます。

explain.executionStats.executionStages.opType

時系列コレクションに対する操作の場合、操作のタイプ。

explain.executionStats.executionStages.bucketFilter

時系列コレクションに対する操作の場合、バケット カタログでクエリされるバケットの数を絞るために使用されるフィルター。

explain.executionStats.executionStages.residualFilter

時系列コレクションに対する操作の場合、バケット カタログをクエリするために使用されるフィルター。

explain.executionStats.executionStages.nBucketsUnpacked

時系列コレクションに対する操作の場合、操作を解決するために開いたバケットの数。

explain.executionStats.executionStages.nMeasurementsDeleted

時系列コレクションに対する操作の場合、削除されたドキュメントの数。

explain.executionStats.executionStages.nMeasurementsInserted

時系列コレクション に対する操作の場合、挿入されたドキュメントの数。

explain.executionStats.executionStages.nMeasurementsMatched

時系列コレクションに対する操作の場合、一致したドキュメントの数。

explain.executionStats.executionStages.nMeasurementsModified

時系列コレクション に対する操作の場合、変更されたドキュメントの数。

explain.executionStats.executionStages.nMeasurementsUpserted

時系列コレクションに対する操作の場合、アップサートされたドキュメントの数。

explain.executionStats.executionStages.inputStage

各inputStage のフィールドは、inputStage.stage の値に応じて異なる可能性があります。次の表では、使用可能なフィールドとフィールドが表示される可能性のあるステージについて説明しています。

各inputStageには、別のinputStageをフィールドとして含めることができます。 出力構造の説明 を参照してください。

フィールド	説明	適用可能なステージ
docsExamined	クエリ実行ステージでスキャンされるドキュメントの数を指定します。	COLLSCAN, FETCH
keysExamined	インデックスをスキャンするクエリ実行ステージの場合、keysExamined はインデックス スキャンのプロセスで検査される限界内のキーと限界外のキーの総数。インデックス スキャンが 1 つの連続したキー範囲で構成されている場合は、範囲内のキーのみを調べる必要があります。インデックスの限界が複数のキー範囲で構成されている場合、インデックス スキャンの実行プロセスでは、ある範囲の終わりから次の範囲の先頭にスキップするために、範囲外のキーを調べることがあります。	IXSCAN
numReads	クエリ実行段階でスキャンされたドキュメントの数、または検査されたインデックス キーの数。 バージョン5.1の新機能。	COLLSCAN, IXSCAN
seeks	インデックス カーソルがインデックス スキャンを完了するための新しい位置を探すのに必要だった回数。	IXSCAN
usedDisk	ステージでディスクに書込み (write) されたかどうか。 バージョン5.3の新機能。	GROUP
spills	ステージがディスクにスピルした回数。 バージョン8.2の新機能。	GROUP, SORT
spilledBytes	ディスクに書込まれたデータの合計量（バイト単位）。 バージョン8.2の新機能。	GROUP, SORT
spilledRecords	ディスクにスピルした個々のレコードの合計数。 バージョン8.2の新機能。	GROUP, SORT
spilledDataStorageSize	スピルしたデータによって使用されたディスク領域の合計（バイト単位）。 バージョン8.2の新機能。	GROUP, SORT
peakTrackedMemBytes	バージョン8.3の新機能。 現在の クエリ操作で使用されている追跡メモリの最大バイト数。 MongoDB 9.0以降、COUNT_SCAN、GEO_NEAR_2D、GEO_NEAR_2DSPHERE、およびUPDATEの各ステージでもこのフィールドが報告されます。	COUNT_SCAN, GEO_NEAR_2D, GEO_NEAR_2DSPHERE, GROUP, SORT, UPDATE

explain.executionStats.allPlansExecution

当選したプランと拒否されたプランの両方について、プラン選択フェーズ中にキャプチャされた部分的な実行情報が含まれます。このフィールドは、explain が allPlansExecution 冗長モードで実行されている場合にのみ存在します。

explain.executionStats.operationMetrics

リソース消費統計が含まれます（0 の場合を除く）。このフィールドが表示されるのは、explain が executionStats冗長モード以上で実行され、かつ profileOperationResourceConsumptionMetrics が有効になっている場合のみです。

警告

MongoDB 8.2 は profileOperationResourceConsumptionMetrics を削除します。そのため、operationMetrics に依存するコードは動作しません。

serverInfo

serverInfo: {   host: <string>,   port: <int>,   version: <string>,   gitVersion: <string>}

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> } ...

統合されたステージ $cursor

stages 配列は、パイプラインのステージと一致しないことがよくあります。最適化中、MongoDBはパイプライン作業の一部をクエリシステムに移動します。クエリシステムはインデックスを使用して、その作業をより効率的に完了できます。例、MongoDBは次の最適化を実行できます。

• 先行する $match、$sort、および $limit ステージは $cursor に吸収されます。吸収された $match はクエリプランでは filter として表示され、吸収された $limit は LIMIT ステージとして表示されます。

• $group と $lookup は、GROUP ステージおよび EQ_LOOKUP ステージとしてクエリプランにプッシュできます。さらに学ぶには、$group の最適化 および $lookup の最適化。 を参照してください。

• インデックスが要求されたソート順序を提供する場合、個別の $sort エントリは表示されません。

• $project また、MongoDBのバージョンや使用するクエリエンジンによっては、他のステージもクエリプランにプッシュされる可能性があります。

このリストは網羅的なものではありません。MongoDBがどのステージを吸収またはプッシュダウンするかは、リリースごとに変更される可能性があります。実行前にMongoDBがパイプラインをどのように再形成するかについての一般的な情報については、「集計パイプラインの最適化」を参照してください。

その結果、stages 配列には、実行したパイプラインよりも少ないエントリが含まれる場合があります。サーバーが実行したステージを確認するには、同じ出力内の stages 配列と command.pipeline フィールドを比較します。

例

以下の集計には3つのパイプラインステージがあります。

db.comments.aggregate(     [        { $match: { date: { $gte: ISODate("2015-01-01") } } },        { $group: { _id: "$movie_id", commentCount: { $sum: 1 } } },        { $sort: { commentCount: -1 } }     ],     { explain: true })

出力には、stages 配列内の2つのエントリのみが含まれます。

{  explainVersion: '2',  stages: [    {      '$cursor': {        queryPlanner: {          namespace: 'sample_mflix.comments',          parsedQuery: { date: { '$gte': ISODate('2015-01-01T00:00:00.000Z') } },          ...          winningPlan: {            isCached: false,            queryPlan: {              stage: 'GROUP',              planNodeId: 3,              inputStage: {                stage: 'COLLSCAN',                planNodeId: 1,                filter: {                  date: { '$gte': ISODate('2015-01-01T00:00:00.000Z') }                },                direction: 'forward'              }            },            ...          },          rejectedPlans: []        },        ...      },      nReturned: Long('697'),      executionTimeMillisEstimate: Long('31')    },    {      '$sort': { sortKey: { commentCount: -1 } },      totalDataSizeSortedBytesEstimate: Long('170765'),      usedDisk: false,      spills: Long('0'),      spilledDataStorageSize: Long('0'),      nReturned: Long('697'),      executionTimeMillisEstimate: Long('31')    }  ],  ...}

出力には以下が表示されます。

• $match ステージは、COLLSCAN ステージの filter として $cursor に吸収されます。

• $group ステージは、GROUP ステージとしてクエリプランにプッシュされます。

• $sort ステージは $cursor の外部にあるため、パイプラインはインメモリソートを実行します。エントリには、スピルメトリクスを使用した集計ステージで説明されている usedDisk フィールドと spills フィールドが含まれます。

最適化によって削除されたパイプライン

クエリシステムがパイプライン内のすべてのステージを実行できる場合、stages 配列は出力に表示されません。代わりに、出力には true に設定された explain.queryPlanner.optimizedPipeline フィールドが含まれ、集計ステージ情報は含まれません。