フィルタ付きのMongo日付範囲インデックス

説明計画の出力からのいくつかの重要なポイント：

• クエリは次の属性に対応します：siteId, status, creationDate, reportCount, assignee, parent
• 勝利プランには2つの段階があります：
  • IX_SCANはcreationDate_1_reportCount_1_label_1を使用します 、これはcreationDateでインデックス付きルックアップを使用します およびreportCount その後、FETCHステージに転送される56のドキュメントを識別します
  • FETCHはIX_SCANステージから56のドキュメントを受け取り、これらのドキュメントに問い合わせてsiteIdを適用します。 、status 、assignee およびparent フィルタ。この問い合わせにより、37のドキュメントが破棄され、19のドキュメントが返されます。

したがって、インデックスはクエリの6つの属性のうち2つだけをカバーし、クエリの残りの4つの属性はドキュメントを調べることによって適用されます。 インデックスではありません 。このクエリを完全にインデックスでカバーする場合は、次のインデックスを作成します。

db.collection.createIndex(
    {siteId: 1, status: 1, creationDate: 1, reportCount: 1, assignee: 1, parent: 1}
) 

このインデックスを設定して再実行すると、（a）MongoDBがこのインデックスを選択し、（b）IX_SCANステージによって転送されるドキュメントの数が、find呼び出しによって返されるドキュメントの数と同じであることがわかります。

私は「見つけるべき」と言います MongoDBが別のインデックスを選択する結果となる可能性のある他の側面があるためです。 $norの使用 および並べ替えステージ（creationDate: 1 ）。インデックスを微調整し、微調整のたびにexplain'on'を指定して実行し、executionStatsでこれらの重要な項目を探すことをお勧めします。 サブドキュメント：

• 「nReturned」
• "totalKeysExamined"
• "totalDocsExamined"

簡単な経験則は次のとおりです。より近いtotalKeysExamined nReturnedになります そして、より近いtotalDocsExamined ゼロにすることです...インデックスカバレッジが向上します。

インデックスのコスト（書き込み時間とインデックスストレージへの影響の観点から）の問題もあるので、非機能要件を検討することをお勧めします-完全なインデックスカバレッジなしで希望の経過時間を達成できますか？そうでない場合は、経験的なテストを続行する必要がありますが、explain()に応じて選択を微調整する準備をしてください。 出力が教えてくれます。