一般に、最も重要な/頻繁なクエリでフィルター基準として最も使用されるフィールドに、最も選択的なフィールドから始めてインデックスを付けることができます。かなりまともな$orがたくさんあるので、あなたのケースで特に興味深いのはおそらくこれです。 s：
ただし、ここで最も重要なことは、 Explain（） 。その理由は、アプリケーションがサポートする必要のあるさまざまな種類のクエリがあり、インデックスのメンテナンスコストから選択する必要があるある時点でトレードオフを行う必要があるためです（例：書き込みロック インデックスの更新とディスク容量の要件の間）、単一のクエリで使用されるすべてのフィールドが単一のインデックスでカバーされる理論的に最速のソリューション。
インデックス作成のトピック全体は少しあいまいなものであり、正確なシナリオに大きく依存します。
- データは大幅に更新されており、書き込みは超高速である必要がありますか（インデックスを小さくしたり小さくしたりする必要があります）、またはデータをかなり安定しており、読み取りを頻繁に行う必要があります（インデックスを大きくしたり大きくしたりします）。
- どのような種類のクエリをサポートする必要がありますか？フィルタに関してはどの程度似ていますか？フィルタの特定の組み合わせは、他の組み合わせよりも可能性が高くなりますか？どのクエリをうまく実行する必要がありますか、どのクエリが少し遅くなる可能性がありますか？
- インデックスが作成される可能性のあるフィールドのデータはどのように分散されますか？
- など...
すべてのクエリが最高のパフォーマンスを発揮するのに役立つ単一のインデックスは見つかりません。また、インデックスを追加したり、既存のインデックスを変更したりすると、クエリオプティマイザが一部のクエリでのインデックスの使用を停止し、代わりに別の実行プランを選択する可能性があります。したがって、インデックス作成または物理データレイアウト（ハードウェアのセットアップ、シャーディングなど）を変更する際に重要なすべてを測定します。最後に、データの分散が予測どおりに均一でない限り、データ量が増えるにつれて、クエリのパフォーマンスを定期的に測定する必要があります。
簡単に言うと、反復的なアプローチを取り、インデックスを追加することから始めます（isBlockedByAdminにインデックスを追加することをお勧めします 、isDelete およびinformation.shares.userId ）次に、クエリのパフォーマンスを測定し、結果に基づいてインデックスを調整します（そして、何度も何度も...）。