MongoDBコンパウンドインデックスパフォーマンス

Question

複合インデックスの基本的な概念を理解するのに困っています。 のは、私はこのスキーマでコレクションを持っているとしましょう：{ field1: 1, field: 2}、唯一field1に、両方のfield1 AND field2にこのメイクセンスをクエリをサポートします：https://docs.mongodb.org/manual/core/index-compound/で

{ 
    _id: 1, 
    field1: 'aaa', 
    field2: 'bbb', 
    field3: 'ccc' 
} 

このインデックスがあること、それは非常に明確に述べている、と私は理解しています。

ここで、フィールド1が常に使用されているすべてのフィールド（1,2,3）でクエリをサポートしたいのですが？ にfield1 AND field2とfield1 AND field3を照会するオプションをサポートしたいと思います。

これらのクエリオプションのそれぞれに対して複合インデックスを作成することは可能ですが、同じパフォーマンスでクエリする化合物を少なくできるかどうかが問題です。例えば

私は、インデックスがあれば、：{field1: 1, field2: 1, field3: 1}を、私はfield1 AND field3を照会、それはこのインデックスを使用しますが、field2のインデックス境界は"[MinKey, MaxKey]"になります。 別のインデックスを作成する価値はありますか：{field1: 1, field3: 1}？

Answer 1

これらのドキュメントとインデックスを含むコレクションを作成しようとすると、クエリで説明を実行すると、mongoはインデックス：{field1: 1, field3: 1}を選択し、他のプランを拒否します。これは、mongoが他のインデックスよりも1つのインデックスを優先することを示しています。

たとえば、次のリターンを説明します。

"winningPlan" : { 
    "stage" : "FETCH", 
    "inputStage" : { 
     "stage" : "IXSCAN", 
     "keyPattern" : { 
      "field1" : 1, 
      "field3" : 1 
     }, 
     "indexName" : "field1_1_field3_1", 
     "isMultiKey" : false, 
     "isUnique" : false, 
     "isSparse" : false, 
     "isPartial" : false, 
     "indexVersion" : 1, 
     "direction" : "forward", 
     "indexBounds" : { 
      "field1" : [ 
       "[\"aaa\", \"aaa\"]" 
      ], 
      "field3" : [ 
       "[\"ccc\", \"ccc\"]" 
      ] 
     } 
    } 
}, 
"rejectedPlans" : [ 
    { 
     "stage" : "FETCH", 
     "filter" : { 
      "field3" : { 
       "$eq" : "ccc" 
      } 
     }, 
     "inputStage" : { 
      "stage" : "IXSCAN", 
      "keyPattern" : { 
       "field1" : 1, 
       "field2" : 1 
      }, 
      "indexName" : "field1_1_field2_1", 
      "isMultiKey" : false, 
      "isUnique" : false, 
      "isSparse" : false, 
      "isPartial" : false, 
      "indexVersion" : 1, 
      "direction" : "forward", 
      "indexBounds" : { 
       "field1" : [ 
        "[\"aaa\", \"aaa\"]" 
       ], 
       "field2" : [ 
        "[MinKey, MaxKey]" 
       ] 
      } 
     } 
    }, 
    { 
     "stage" : "FETCH", 
     "inputStage" : { 
      "stage" : "IXSCAN", 
      "keyPattern" : { 
       "field1" : 1, 
       "field2" : 1, 
       "field3" : 1 
      }, 
      "indexName" : "field1_1_field2_1_field3_1", 
      "isMultiKey" : false, 
      "isUnique" : false, 
      "isSparse" : false, 
      "isPartial" : false, 
      "indexVersion" : 1, 
      "direction" : "forward", 
      "indexBounds" : { 
       "field1" : [ 
        "[\"aaa\", \"aaa\"]" 
       ], 
       "field2" : [ 
        "[MinKey, MaxKey]" 
       ], 
       "field3" : [ 
        "[\"ccc\", \"ccc\"]" 
       ] 
      } 
     } 
    } 
] 

は、しかし、インデックスサイズの問題があり、すべてのインデックスかどうかは、データベースのワーキングセットと一緒にRAMに収まる作成することでしょう。それらがいなければ、ディスク上のインデックスを保持します。これは、読み込みがかなり遅くなります。最高の妥協点は、3つのフィールドすべてでインデックスを使用することです。なぜなら、これはインデックスよりも優れており、3つのインデックスよりメンテナンスが少ないからです。