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

explain の結果

項目一覧

  • 出力構造の説明
  • MongoDB 5.1 以降の explain 出力
  • queryPlanner
  • executionStats
  • serverInfo
  • $lookup パイプライン ステージを使用するクエリの実行プラン統計
  • コレクションスキャン
  • カバード クエリ
  • $or
  • $sort ステージと $group ステージ
  • ソート ステージ

クエリプランとクエリプランの実行統計に関する情報を返すために、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 、シャードから孤立したドキュメントのフィルタリング用

  • BATCHED_DELETE 複数のドキュメントを内部的に一括削除する場合(MongoDB 6.1 以降)

このセクションで示されているのは、MongoDB 5.1 以降の explain 出力です。MongoDB 5.1 より前のバージョンの explain 出力を確認するには、該当バージョンのドキュメントを参照してください。

explain.explainVersion

整数フィールドです。

explainVersion はプランの出力形式のバージョンです("1""2" など)。

バージョン 5.1 で追加

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

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

シャーディングされていないコレクションの場合、explain は次の queryPlanner 情報を返します。

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

シャーディングされたコレクションの場合、explain には shards フィールドの各アクセスされたシャード向けの主要クエリ プランナーとサーバーに関する情報が含まれます。

{
queryPlanner: {
mongosPlannerVersion: <int>
winningPlan: {
stage: <STAGE1>,
shards: [
{
shardName: <string>,
connectionString: <string>,
serverInfo: {
...
},
namespace: <string>,
indexFilterSet: <boolean>,
parsedQuery: {
...
},
queryHash: <hexadecimal string>,
planCacheKey: <hexadecimal string>,
maxIndexedOrSolutionsReached: <boolean>,
maxIndexedAndSolutionsReached: <boolean>,
maxScansToExplodeReached: <boolean>,
winningPlan: {
stage: <STAGE1>,
inputStage: {
stage: <string>,
...
}
},
rejectedPlans: [
<candidate plan1>,
]
}
]
}
}
}
explain.queryPlanner

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

explain.queryPlanner.namespace

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

explain.queryPlanner.indexFilterSet

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

explain.queryPlanner.queryHash

クエリシェイプのハッシュを表す 16 進数の文字列で、クエリシェイプのみに依存します。queryHash は、同じクエリシェイプでもスロー クエリ(書き込み (write) 操作のクエリフィルターを含む)を識別するのに役立ちます。

注意

他のハッシュ関数と同様に、2 つの異なるクエリシェイプで同じハッシュ値が生成される場合があります。ただし、異なるクエリシェイプ間でハッシュ衝突が発生する可能性は低くなります。

queryHashplanCacheKey の詳細については、「queryHashplanCacheKey」を参照してください。

explain.queryPlanner.planCacheKey

クエリに関連付けられたプラン キャッシュ エントリのキーのハッシュです。

explain.queryPlanner.queryHash と違って explain.queryPlanner.planCacheKey は、クエリシェイプとそのシェイプで現在使用可能なインデックスの両方の関数です。具体的には、クエリシェイプをサポート可能なインデックスが追加または削除された場合、planCacheKey 値は変化しますが、queryHash の値は変化しません。

queryHashplanCacheKey の詳細については、「queryHashplanCacheKey」を参照してください。

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

クエリオプティマイザによって検討および拒否された候補プランの配列です。他に候補プランがなければ、配列は空にできます。

返されたexplain.executionStats情報には、当選プランの実行の詳細が表示されます。 結果にexecutionStatsを含めるには、次のいずれかで explain を実行する必要があります。

これらの例では、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

クエリの実行中に検査されたドキュメントの数。ドキュメントを検査する一般的なクエリ実行ステージは、COLLSCANFETCH です。

注意

explain.executionStats.totalDocsExamined は、返されたドキュメント数ではなく、検査されたドキュメントの合計数を示します。たとえば、ステージではフィルターを適用するためにドキュメントを調べることができます。ドキュメントがフィルターで除外された場合、そのドキュメントは検査済みですが、クエリ結果セットの一部として返されません。

クエリの実行中にドキュメントが複数回検査された場合、 explain.executionStats.totalDocsExaminedはそれぞれの検査でカウントします。 つまり、 explain.executionStats.totalDocsExaminedは検査された一意のドキュメントの合計数ではありません

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

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

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

フィールド
説明
適用可能なステージ

docsExamined

クエリ実行ステージでスキャンされるドキュメントの数を指定します。

COLLSCAN, FETCH

keysExamined

インデックスをスキャンするクエリ実行ステージの場合、keysExamined はインデックス スキャンのプロセスで検査される限界内のキーと限界外のキーの総数。インデックス スキャンが 1 つの連続したキー範囲で構成されている場合は、範囲内のキーのみを調べる必要があります。インデックスの限界が複数のキー範囲で構成されている場合、インデックス スキャンの実行プロセスでは、ある範囲の終わりから次の範囲の先頭にスキップするために、範囲外のキーを調べることがあります。

IXSCAN

numReads

クエリ実行段階でスキャンされたドキュメントの数、または検査されたインデックス キーの数。

バージョン 5.1 で追加

COLLSCAN, IXSCAN

seeks

インデックス カーソルがインデックス スキャンを完了するための新しい位置を探すのに必要だった回数。

IXSCAN

spilledBytesApprox

ステージ内でディスクにスピルしたインメモリのバイト数の概算。

バージョン 5.3 で追加。

GROUP

spilledRecords

ステージ内でディスクにスピルした、生成されたレコードの数。

バージョン 5.3 で追加。

GROUP

usedDisk

ステージでディスクに書込み (write) されたかどうか。

バージョン 5.3 で追加。

GROUP

explain.executionStats.allPlansExecution

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

explain.executionStats.operationMetrics

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

シャーディングされていないコレクションの場合、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>
}
...

バージョン 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.totalDocsExamined

クエリの実行中に調査されたドキュメントの数。

explain.totalKeysExamined

検査されたインデックス キーの数。

explain.collectionScans

クエリの実行中にコレクションスキャンが発生した回数です。コレクションスキャン中に、コレクション内の各ドキュメントがクエリ述語と比較されます。クエリをカバーする適切なインデックスが存在しない場合は、コレクションスキャンが実行されます。

explain.indexesUsed

クエリで使用されるインデックス名を含む文字列の配列。

explain.executionTimeMillisEstimate

クエリ実行の推定時間(ミリ秒単位)。

クエリ プランナーがコレクションスキャンを選択した場合、explain の結果には COLLSCAN ステージが含まれます。

クエリ プランナーによってインデックスが選択された場合、explain の結果には IXSCAN ステージが加わります。このステージでは、インデックス キーのパターン、トラバースの方向、インデックスの限界などの情報が提供されます。

MongoDB 5.3 以降では、クエリ プランナーでクラスター化されたコレクションクラスター化されたインデックスが選択され、かつ検索するインデックス部分を定義する限界がクエリに含まれている場合、explain の結果には CLUSTERED_IXSCAN ステージが加わります。このステージでは、クラスター化されたインデックスキーとインデックスの限界に関する情報が提供されます。

クエリ プランナーによってクラスター化されたコレクションクラスター化されたインデックスが選択され、かつクエリに限界が含まれていない場合、クエリでは、限界抜きでコレクションのスキャンが実行され、explain の結果には COLLSCAN ステージが加わります。

注意

限界が設定されていないクエリで、クラスター化インデックスを使用するものは、コレクションのフル スキャンが必要なため、notablescan パラメーターでは許可されません。

コレクションスキャンの実行統計の詳細については、Explain プラン 結果の解釈を参照してください。

インデックスがクエリをカバーする場合、MongoDB ではクエリの条件を一致させること、およびインデックスキーのみを使用して結果を返すこともできます。MongoDBでは、クエリの一部を実行するためにコレクションのドキュメントを検査する必要はありません。

インデックスがクエリを補う場合、explain の結果には FETCH ステージの子孫ではないIXSCAN ステージがあり、executionStats では explain.executionStats.totalDocsExamined0 です。

MongoDB が $or 式にインデックスを使用する場合、結果にはインデックスの詳細を示す explain.queryPlanner.winningPlan.inputStages 配列を含む、OR ステージが含まれます。以下がその例です。

{
stage: 'OR',
inputStages: [
{
stage: 'IXSCAN',
...
},
{
stage : 'IXSCAN',
...
},
...
]
}

MongoDB の以前のバージョンでは、cursor.explain() インデックスの詳細を示す clauses 配列を返していました。

explain が、executionStats または allPlansExecution 冗長モードのいずれかで実行されると、$sort および $group ステージに追加の出力があります。

ステージ
フィールド
タイプ
説明

totalDataSizeSortedBytesEstimate

long

$sort ステージで処理される推定バイト数。

usedDisk

ブール値

$sortステージでディスクに書込み(write)されたかどうか。

totalOutputDataSizeBytes

long

$group ステージによって出力されるすべてのドキュメントの合計サイズの推定値(バイト単位)。

usedDisk

ブール値

$groupステージでディスクに書込み(write)されたかどうか。

spillFileSizeBytes

long

$group ステージでディスクに書込まれたスピル ファイルのサイズ。圧縮のため、spillFileSizeBytes の値は numBytesSpilledEstimate 以下である必要があります。

numBytesSpilledEstimate

long

圧縮前の $group ステージでディスクに書込まれるバイト数の推定値です。

MongoDB では、1 つまたは複数のインデックスを使用してソート順序を取得できない場合、結果にはブロッキングソート操作を指し示す SORT ステージが含まれます。ブロッキングソートは、コレクションまたはデータベースに対する同時操作をブロックしません。この名前は、SORT ステージが出力ドキュメントを返す前にすべての入力ドキュメントを読み取り、その特定のクエリのデータフローをブロックするという要件に由来しています。

MongoDB がブロッキングソート操作に 100 メガバイトを超えるシステム メモリを必要とする場合、クエリが cursor.allowDiskUse() を指定しない限り、MongoDB はエラーを返します。cursor.allowDiskUse() では、ブロッキングソート操作の処理中に、MongoDB がディスク上の一時ファイルを使用して、100 メガバイトのシステムメモリ制限を超えるデータを保存できるようにします。explain プランに明示的な SORT ステージが含まれていない場合には、MongoDB はインデックスを使用して並べ替え順を取得できます。

戻る

パフォーマンスの分析