Mongodbは集約フレームワークについて説明します

MongoDBバージョン3.0以降、順序を変更するだけです

collection.aggregate(...).explain()

に

collection.explain().aggregate(...)

希望する結果が得られます（ここにドキュメントがあります）。

古いバージョン>=2.6の場合、explainを使用する必要があります集約パイプライン操作のオプション

`explain:true`

db.collection.aggregate([
    { $project : { "Tags._id" : 1 }},
    { $unwind : "$Tags" },
    { $match: {$or: [{"Tags._id":"tag1"},{"Tags._id":"tag2"}]}},
    { $group: { 
        _id : "$_id",
        count: { $sum:1 } 
    }},
    {$sort: {"count":-1}}
  ],
  {
    explain:true
  }
)

Aggregation Frameworkの重要な考慮事項は、インデックスはパイプラインの初期データをフェッチするためにのみ使用できることです（例：$matchの使用）、$sort 、$geonear パイプラインの開始時）および後続の$lookup および$graphLookup ステージ。データが処理のために集約パイプラインにフェッチされると（たとえば、$projectなどのステージを通過する、$unwind 、および$group ）それ以上の操作はメモリ内で行われます（allowDiskUseの場合は一時ファイルを使用する可能性があります）オプションが設定されています。

パイプラインの最適化

一般に、集約パイプラインは次の方法で最適化できます。

$matchでパイプラインを開始する処理を関連ドキュメントに制限する段階。
最初の$matchを確認する / $sort ステージは効率的なインデックスによってサポートされています。
$matchを使用してデータを早期にフィルタリングする、$limit 、および$skip 。
不要な段階とドキュメント操作を最小限に抑えます（複雑な集計体操が必要な場合は、おそらくスキーマを再検討します）。
MongoDBサーバーをアップグレードした場合は、新しい集計演算子を利用します。たとえば、MongoDB 3.4では、配列、文字列、ファセットの操作のサポートなど、多くの新しい集計ステージと式が追加されました。

MongoDBサーバーのバージョンに応じて自動的に行われる集約パイプラインの最適化もいくつかあります。たとえば、出力結果に影響を与えることなく実行を改善するために、隣接するステージを合体および/または並べ替えることができます。

制限

MongoDB 3.4と同様に、Aggregation Framework explain オプションは、パイプラインの処理方法に関する情報を提供しますが、executionStatsと同じレベルの詳細をサポートしていません find()のモードクエリ。最初のクエリ実行の最適化に集中している場合は、同等のfind().explain()を確認することが有益であることがわかります。 executionStatsを使用したクエリまたはallPlansExecution 冗長性。

集約パイプラインの最適化/プロファイル作成に役立つ、より詳細な実行統計に関して、MongoDB課題トラッカーで監視/賛成する関連機能リクエストがいくつかあります。

SERVER-19758：「executionStats」と「allPlansExecution」のexplainモードをaggregationexplainに追加します
SERVER-21784：各集計パイプラインステージの実行統計を追跡し、explainを介して公開します
SERVER-22622：「from」コレクションのクエリプランを示すように$lookupexplainを改善しました