MongoDB インデックスのベストプラクティス-SQL-php.cn

ホームページ

データベース

SQL

MongoDB インデックスのベストプラクティス

步履不停

Jun 24, 2019 pm 05:36 PM

mongodb索引

MongoDB インデックスのベストプラクティス

まえがき

ほとんどの開発者は、インデックス作成の方が高速であることを知っています。しかし、実際のプロセスでは、次のような疑問や困難に遭遇することがよくあります:

クエリを実行するフィールドにはさまざまなケースがあります。クエリに含まれるすべてのフィールドにインデックスを付ける必要がありますか?
複合インデックスと単一フィールドのどちらを選択するか?両方を追加するか、それぞれに単一フィールドを追加する方がよいでしょうか?
インデックスを追加すると副作用はありますか?
インデックスは追加されましたが、まだ速度が十分ではありませんか?何をするか？

この記事では、インデックス作成の基本知識を説明し、上記の質問に答えます。

1. インデックスとは正確には何ですか?

インデックスを扱うほとんどの開発者は、インデックスが本のカタログに似ていることをおそらく知っています。必要なコンテンツを見つけ、カタログから適切なキーワードを見つけて、対応するページ番号を見つける必要があります。の章を参照して、具体的な内容を見つけてください。
データ構造において、最も単純なインデックスの実装はハッシュマップに似ており、キーワードキーを介して特定の場所にマップされ、特定のコンテンツが検索されます。ただし、ハッシュ化以外にも、インデックス付けを実装する方法はたくさんあります。

(1)index

hash / b-tree / b-treeの複数の実装方法と特徴 redis HSET / MongoDB&PostgreSQL / MySQL

ハッシュマップ

MongoDB インデックスのベストプラクティス

##B ツリーと B ツリーの違いを図で参照してください:

MongoDB インデックスのベストプラクティス

b ツリーの葉以外の葉にはデータを保存できます

アルゴリズム検索の複雑さ:

b ツリーに近い O(1)~ O(Log(n)) より速い平均検索時間、不安定なクエリ時間
b ツリー O(Log(n)) 連続データ、クエリの安定性

MongoDB の実装が b ではなく b-tree を選択する理由については -木？

これについて説明する記事はインターネット上にたくさんありますが、この記事の焦点ではありません。

(2) データとインデックスの格納

インデックスは可能な限りメモリ上に格納し、その後にデータを格納します。 MongoDB インデックスのベストプラクティス必要なインデックスのみを保持し、メモリをできるだけ賢く使用するように注意してください。
インデックスメモリがいっぱいになると、ディスクの読み取りが容易になり、速度が遅くなります。

(3) インデックスの実装と保存原理を知った上での感想

insert/update/delete でリバランスツリーがトリガーされるため、データの追加、削除、変更を行うとインデックスがトリガーされます変更するとパフォーマンスが失われます。インデックスは多いほど良いです。この場合、どのフィールドをインデックスとして選択すればよいでしょうか?クエリでこれらの条件が使用されている場合はどうすればよいですか?

最も単純なハッシュマップを例に挙げます。複雑度が O(1) ではなく、いわゆる O(1) に近いのはなぜですか。キーの競合/重複があるため、DB がキーを検索するときに、キーが競合しているデータが大量にある場合は、順番に検索を続ける必要があります。キー選択を調べる B ツリーにも同じことが当てはまります。
したがって、ほとんどの開発者がよく犯す間違いは、区別のないキーにインデックスを付けることです。例: 多くのコレクションには、数十万以上のタイプ/ステータスドキュメントの集中カテゴリのみが含まれており、通常、この種のインデックスは役に立ちません。

2. 複合インデックス

(1) 複合インデックスは多ければ多いほど良いです

これ以上冗長なインデックスを構築したくない場合、開発チームは複合インデックスを選択します。 & 単一フィールド。非常に混乱することがあります。典型的な遭遇シナリオに基づいていくつかの実験を行ってみましょう:

ここでローンのコレクションが作成されます。データが 100 個のみになるように簡略化されています。これは、_id、userId、status (ローンステータス)、amount (金額) を含むローンテーブルです。

db.loans.count()100

db.loans.find({ "userId" : "59e022d33f239800129c61c7", "status" : "repayed", }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "$and" : [
   {
     "status" : {
       "$eq" : "repayed"
     }
   },
   {
     "userId" : {
       "$eq" : "59e022d33f239800129c61c7"
     }
   }
 ]
},
"queryHash" : "15D5A9A1",
"planCacheKey" : "15D5A9A1",
"winningPlan" : {
 "stage" : "COLLSCAN",
 "filter" : {
   "$and" : [
     {
       "status" : {
         "$eq" : "repayed"
       }
     },
     {
       "userId" : {
         "$eq" : "59e022d33f239800129c61c7"
       }
     }
   ]
 },
 "direction" : "forward"
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

注上記の COLLSCAN はインデックスがないため、テーブル全体をスキャンします。次に、いくつかのインデックスをそれぞれ作成します。

ステップ 1 まず、{userId:1, status:1}

db.loans.createIndex({userId:1, status:1})
{
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 1,
"numIndexesAfter" : 2,
"ok" : 1
}

db.loans.find({ "userId" : "59e022d33f239800129c61c7", "status" : "repayed", }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "$and" : [
   {
     "status" : {
       "$eq" : "repayed"
     }
   },
   {
     "userId" : {
       "$eq" : "59e022d33f239800129c61c7"
     }
   }
 ]
},
"queryHash" : "15D5A9A1",
"planCacheKey" : "BB87F2BA",
"winningPlan" : {
 "stage" : "FETCH",
 "inputStage" : {
   "stage" : "IXSCAN",
   "keyPattern" : {
     "userId" : 1,
     "status" : 1
   },
   "indexName" : "userId_1_status_1",
   "isMultiKey" : false,
   "multiKeyPaths" : {
     "userId" : [ ],
     "status" : [ ]
   },
   "isUnique" : false,
   "isSparse" : false,
   "isPartial" : false,
   "indexVersion" : 2,
   "direction" : "forward",
   "indexBounds" : {
     "userId" : [
       "["59e022d33f239800129c61c7", "59e022d33f239800129c61c7"]"
     ],
     "status" : [
       "["repayed", "repayed"]"
     ]
   }
 }
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

を作成します。結果: {userId:1, status:1} が優勝プランとしてヒットします。

#ステップ 2: 一般的なインデックス userId を作成します。

db.loans.createIndex({userId:1})
{
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 2,
"numIndexesAfter" : 3,
"ok" : 1
}

db.loans.find({ "userId" : "59e022d33f239800129c61c7", "status" : "repayed", }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "$and" : [
   {
     "status" : {
       "$eq" : "repayed"
     }
   },
   {
     "userId" : {
       "$eq" : "59e022d33f239800129c61c7"
     }
   }
 ]
},
"queryHash" : "15D5A9A1",
"planCacheKey" : "1B1A4861",
"winningPlan" : {
 "stage" : "FETCH",
 "inputStage" : {
   "stage" : "IXSCAN",
   "keyPattern" : {
     "userId" : 1,
     "status" : 1
   },
   "indexName" : "userId_1_status_1",
   "isMultiKey" : false,
   "multiKeyPaths" : {
     "userId" : [ ],
     "status" : [ ]
   },
   "isUnique" : false,
   "isSparse" : false,
   "isPartial" : false,
   "indexVersion" : 2,
   "direction" : "forward",
   "indexBounds" : {
     "userId" : [
       "[\"59e022d33f239800129c61c7\", \"59e022d33f239800129c61c7\"]"
     ],
     "status" : [
       "[\"repayed\", \"repayed\"]"
     ]
   }
 }
},
"rejectedPlans" : [
 {
   "stage" : "FETCH",
   "filter" : {
     "status" : {
       "$eq" : "repayed"
     }
   },
   "inputStage" : {
     "stage" : "IXSCAN",
     "keyPattern" : {
       "userId" : 1
     },
     "indexName" : "userId_1",
     "isMultiKey" : false,
     "multiKeyPaths" : {
       "userId" : [ ]
     },
     "isUnique" : false,
     "isSparse" : false,
     "isPartial" : false,
     "indexVersion" : 2,
     "direction" : "forward",
     "indexBounds" : {
       "userId" : [
         "["59e022d33f239800129c61c7", "59e022d33f239800129c61c7"]"
       ]
     }
   }
 }
]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

DB は、より適切な実行プランとして {userId:1, status:1} を検出することに注意してください。

db.loans.find({ "userId" : "59e022d33f239800129c61c7" }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "userId" : {
   "$eq" : "59e022d33f239800129c61c7"
 }
},
"queryHash" : "B1777DBA",
"planCacheKey" : "1F09D68E",
"winningPlan" : {
 "stage" : "FETCH",
 "inputStage" : {
   "stage" : "IXSCAN",
   "keyPattern" : {
     "userId" : 1
   },
   "indexName" : "userId_1",
   "isMultiKey" : false,
   "multiKeyPaths" : {
     "userId" : [ ]
   },
   "isUnique" : false,
   "isSparse" : false,
   "isPartial" : false,
   "indexVersion" : 2,
   "direction" : "forward",
   "indexBounds" : {
     "userId" : [
       "["59e022d33f239800129c61c7", "59e022d33f239800129c61c7"]"
     ]
   }
 }
},
"rejectedPlans" : [
 {
   "stage" : "FETCH",
   "inputStage" : {
     "stage" : "IXSCAN",
     "keyPattern" : {
       "userId" : 1,
       "status" : 1
     },
     "indexName" : "userId_1_status_1",
     "isMultiKey" : false,
     "multiKeyPaths" : {
       "userId" : [ ],
       "status" : [ ]
     },
     "isUnique" : false,
     "isSparse" : false,
     "isPartial" : false,
     "indexVersion" : 2,
     "direction" : "forward",
     "indexBounds" : {
       "userId" : [
         "["59e022d33f239800129c61c7", "59e022d33f239800129c61c7"]"
       ],
       "status" : [
         "[MinKey, MaxKey]"
       ]
     }
   }
 }
]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

DB が {userId:1} をより適切な実行プランとして検出していることに注目してください。ええと、予想どおりです。

db.loans.find({ "status" : "repayed" }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "status" : {
   "$eq" : "repayed"
 }
},
"queryHash" : "E6304EB6",
"planCacheKey" : "7A94191B",
"winningPlan" : {
 "stage" : "COLLSCAN",
 "filter" : {
   "status" : {
     "$eq" : "repayed"
   }
 },
 "direction" : "forward"
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

興味深い部分: ステータスはインデックスにヒットしません。フルテーブルスキャン次のステップ、並べ替えを追加します:

db.loans.find({ "userId" : "59e022d33f239800129c61c7" }).sort({status:1}).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "userId" : {
   "$eq" : "59e022d33f239800129c61c7"
 }
},
"queryHash" : "F5ABB1AA",
"planCacheKey" : "764CBAA8",
"winningPlan" : {
 "stage" : "FETCH",
 "inputStage" : {
   "stage" : "IXSCAN",
   "keyPattern" : {
     "userId" : 1,
     "status" : 1
   },
   "indexName" : "userId_1_status_1",
   "isMultiKey" : false,
   "multiKeyPaths" : {
     "userId" : [ ],
     "status" : [ ]
   },
   "isUnique" : false,
   "isSparse" : false,
   "isPartial" : false,
   "indexVersion" : 2,
   "direction" : "forward",
   "indexBounds" : {
     "userId" : [
       "["59e022d33f239800129c61c7", "59e022d33f239800129c61c7"]"
     ],
     "status" : [
       "[MinKey, MaxKey]"
     ]
   }
 }
},
"rejectedPlans" : [
 {
   "stage" : "SORT",
   "sortPattern" : {
     "status" : 1
   },
   "inputStage" : {
     "stage" : "SORT_KEY_GENERATOR",
     "inputStage" : {
       "stage" : "FETCH",
       "inputStage" : {
         "stage" : "IXSCAN",
         "keyPattern" : {
           "userId" : 1
         },
         "indexName" : "userId_1",
         "isMultiKey" : false,
         "multiKeyPaths" : {
           "userId" : [ ]
         },
         "isUnique" : false,
         "isSparse" : false,
         "isPartial" : false,
         "indexVersion" : 2,
         "direction" : "forward",
         "indexBounds" : {
           "userId" : [
             "["59e022d33f239800129c61c7", "59e022d33f239800129c61c7"]"
           ]
         }
       }
     }
   }
 }
]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

(2) その他の試み

興味深い部分: ステータスがインデックスにヒットしません

db.loans.find({ "status" : "repayed","userId" : "59e022d33f239800129c61c7", }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "$and" : [
   {
     "status" : {
       "$eq" : "repayed"
     }
   },
   {
     "userId" : {
       "$eq" : "59e022d33f239800129c61c7"
     }
   }
 ]
},
"queryHash" : "15D5A9A1",
"planCacheKey" : "1B1A4861",
"winningPlan" : {
 "stage" : "FETCH",
 "inputStage" : {
   "stage" : "IXSCAN",
   "keyPattern" : {
     "userId" : 1,
     "status" : 1
   },
   "indexName" : "userId_1_status_1",
   "isMultiKey" : false,
   "multiKeyPaths" : {
     "userId" : [ ],
     "status" : [ ]
   },
   "isUnique" : false,
   "isSparse" : false,
   "isPartial" : false,
   "indexVersion" : 2,
   "direction" : "forward",
   "indexBounds" : {
     "userId" : [
       "[\"59e022d33f239800129c61c7\", \"59e022d33f239800129c61c7\"]"
     ],
     "status" : [
       "[\"repayed\", \"repayed\"]"
     ]
   }
 }
},
"rejectedPlans" : [
 {
   "stage" : "FETCH",
   "filter" : {
     "status" : {
       "$eq" : "repayed"
     }
   },
   "inputStage" : {
     "stage" : "IXSCAN",
     "keyPattern" : {
       "userId" : 1
     },
     "indexName" : "userId_1",
     "isMultiKey" : false,
     "multiKeyPaths" : {
       "userId" : [ ]
     },
     "isUnique" : false,
     "isSparse" : false,
     "isPartial" : false,
     "indexVersion" : 2,
     "direction" : "forward",
     "indexBounds" : {
       "userId" : [
         "["59e022d33f239800129c61c7", "59e022d33f239800129c61c7"]"
       ]
     }
   }
 }
]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

推測したように、ヒットインデックスはクエリの各フィールドの順序とは関係ありません。

興味深い部分に戻ります。インデックス {userId:1}

db.loans.dropIndex({"userId":1})
{ "nIndexesWas" : 3, "ok" : 1 }

db.loans.find({"userId" : "59e022d33f239800129c61c7", }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "userId" : {
   "$eq" : "59e022d33f239800129c61c7"
 }
},
"queryHash" : "B1777DBA",
"planCacheKey" : "5776AB9C",
"winningPlan" : {
 "stage" : "FETCH",
 "inputStage" : {
   "stage" : "IXSCAN",
   "keyPattern" : {
     "userId" : 1,
     "status" : 1
   },
   "indexName" : "userId_1_status_1",
   "isMultiKey" : false,
   "multiKeyPaths" : {
     "userId" : [ ],
     "status" : [ ]
   },
   "isUnique" : false,
   "isSparse" : false,
   "isPartial" : false,
   "indexVersion" : 2,
   "direction" : "forward",
   "indexBounds" : {
     "userId" : [
       "["59e022d33f239800129c61c7", "59e022d33f239800129c61c7"]"
     ],
     "status" : [
       "[MinKey, MaxKey]"
     ]
   }
 }
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

DB 実行アナライザーは、インデックス {userId:1, status:1} が削除できると考えます。より良いですが、複合インデックスがヒットしません。これは、ステータスが主要なフィールドではないためです。

db.loans.find({ "status" : "repayed" }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "status" : {
   "$eq" : "repayed"
 }
},
"queryHash" : "E6304EB6",
"planCacheKey" : "7A94191B",
"winningPlan" : {
 "stage" : "COLLSCAN",
 "filter" : {
   "status" : {
     "$eq" : "repayed"
   }
 },
 "direction" : "forward"
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

もう一度並べ替え角度を変更し、前のクエリと並べ替えと交換します。前のクエリは:

db.loans.find({userId:1}).sort({ "status" : "repayed" })

違いがわかりますか?

db.loans.find({ "status" : "repayed" }).sort({userId:1}).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "status" : {
   "$eq" : "repayed"
 }
},
"queryHash" : "56EA6313",
"planCacheKey" : "2CFCDA7F",
"winningPlan" : {
 "stage" : "FETCH",
 "filter" : {
   "status" : {
     "$eq" : "repayed"
   }
 },
 "inputStage" : {
   "stage" : "IXSCAN",
   "keyPattern" : {
     "userId" : 1,
     "status" : 1
   },
   "indexName" : "userId_1_status_1",
   "isMultiKey" : false,
   "multiKeyPaths" : {
     "userId" : [ ],
     "status" : [ ]
   },
   "isUnique" : false,
   "isSparse" : false,
   "isPartial" : false,
   "indexVersion" : 2,
   "direction" : "forward",
   "indexBounds" : {
     "userId" : [
       "[MinKey, MaxKey]"
     ],
     "status" : [
       "[MinKey, MaxKey]"
     ]
   }
 }
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

ご想像のとおり、インデックスにヒットします。

もう一度プレイして、主要なフィールドテストを確認してみましょう:

db.loans.dropIndex("userId_1_status_1")
{ "nIndexesWas" : 2, "ok" : 1 }

db.loans.getIndexes()
[
{
"v" : 2,
"key" : {
 "id" : 1
},
"name" : "id_",
"ns" : "cashLoan.loans"
}
]

db.loans.createIndex({status:1, userId:1})
{
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 1,
"numIndexesAfter" : 2,
"ok" : 1
}

db.loans.getIndexes()
[
{
"v" : 2,
"key" : {
 "id" : 1
},
"name" : "id_",
"ns" : "cashLoan.loans"
},
{
"v" : 2,
"key" : {
 "status" : 1,
 "userId" : 1
},
"name" : "status_1_userId_1",
"ns" : "cashLoan.loans"
}
]

db.loans.find({ "status" : "repayed" }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "status" : {
   "$eq" : "repayed"
 }
},
"queryHash" : "E6304EB6",
"planCacheKey" : "7A94191B",
"winningPlan" : {
 "stage" : "FETCH",
 "inputStage" : {
   "stage" : "IXSCAN",
   "keyPattern" : {
     "status" : 1,
     "userId" : 1
   },
   "indexName" : "status_1_userId_1",
   "isMultiKey" : false,
   "multiKeyPaths" : {
     "status" : [ ],
     "userId" : [ ]
   },
   "isUnique" : false,
   "isSparse" : false,
   "isPartial" : false,
   "indexVersion" : 2,
   "direction" : "forward",
   "indexBounds" : {
     "status" : [
       "["repayed", "repayed"]"
     ],
     "userId" : [
       "[MinKey, MaxKey]"
     ]
   }
 }
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

db.loans.getIndexes()
[
{
"v" : 2,
"key" : {
 "id" : 1
},
"name" : "id_",
"ns" : "cashLoan.loans"
},
{
"v" : 2,
"key" : {
 "status" : 1,
 "userId" : 1
},
"name" : "status_1_userId_1",
"ns" : "cashLoan.loans"
}
]

db.loans.find({"userId" : "59e022d33f239800129c61c7", }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "cashLoan.loans",
"indexFilterSet" : false,
"parsedQuery" : {
 "userId" : {
   "$eq" : "59e022d33f239800129c61c7"
 }
},
"queryHash" : "B1777DBA",
"planCacheKey" : "5776AB9C",
"winningPlan" : {
 "stage" : "COLLSCAN",
 "filter" : {
   "userId" : {
     "$eq" : "59e022d33f239800129c61c7"
   }
 },
 "direction" : "forward"
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "RMBAP",
"port" : 27017,
"version" : "4.1.11",
"gitVersion" : "1b8a9f5dc5c3314042b55e7415a2a25045b32a94"
},
"ok" : 1
}

看完这个试验，明白了 {userId:1, status:1} vs {status:1,userId:1} 的差别了吗？

PS：这个case 里面其实status 区分度不高，这里只是作为实例展示。

三、总结：

注意使用上、使用频率上、区分高的/常用的在前面；
如果需要减少索引以节省memory/提高修改数据的性能的话，可以保留区分度高，常用的，去除区分度不高，不常用的索引。
学会用explain（）验证分析性能：

DB 一般都有执行器优化的分析，MySQL & MongoDB 都是用explain 来做分析。
语法上MySQL :

explain your_sql

MongoDB:

yoursql.explain()

总结典型：理想的查询是结合explain 的指标，他们通常是多个的混合:

IXSCAN : 索引命中；
Limit : 带limit；
Projection : 相当于非 select * ；
Docs Size less is better ；
Docs Examined less is better ；
nReturned=totalDocsExamined=totalKeysExamined ；
SORT in index ：sort 也是命中索引，否则，需要拿到数据后，再执行一遍排序；
Limit Array elements ：限定数组返回的条数，数组也不应该太多数据，否则schema 设计不合理。

彩蛋

文末，还有最开头1个问题没回答：如果我的索引改加的都加了，还不够快,怎么办？
留个悬念，之后再写一篇。

更多PHP相关技术文章，请访问PHP教程栏目进行学习！

以上がMongoDB インデックスのベストプラクティスの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明

この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

SQLインデックス戦略：クエリパフォーマンスを桁違いに改善するApr 11, 2025 am 12:04 AM

SQLインデックスは、巧妙なデザインを通じてクエリパフォーマンスを大幅に改善できます。 1. Bツリー、ハッシュ、フルテキストインデックスなどの適切なインデックスタイプを選択します。 2。複合インデックスを使用して、マルチフィールドクエリを最適化します。 3.オーバーインデックスを避けて、データメンテナンスのオーバーヘッドを減らします。 4.不要なインデックスの再構築や削除など、定期的にインデックスを維持します。

SQLで制約を削除する方法Apr 10, 2025 pm 12:21 PM

SQLの制約を削除するには、次の手順を実行します。削除する制約名を特定します。 ALTER TABLEステートメントを使用してください：Table Table Name Drop Constraint Constraint Nameを変更します。削除を確認します。

SQLトリガーを設定する方法Apr 10, 2025 pm 12:18 PM

SQLトリガーは、特定のイベントが指定されたテーブルで実行されたときに特定のアクションを自動的に実行するデータベースオブジェクトです。 SQLトリガーをセットアップするには、トリガー名、テーブル名、イベントタイプ、トリガーコードを含むCreate Triggerステートメントを使用できます。トリガーコードは、ASキーワードを使用して定義され、SQLまたはPL/SQLステートメントまたはブロックが含まれます。トリガー条件を指定することにより、Where句を使用して、トリガーの実行範囲を制限できます。トリガー操作は、インサート、更新、または削除ステートメントを使用してトリガーコードで実行できます。新しいキーワードと古いキーワードを使用して、トリガーコードの影響を受けるキーワードを参照できます。

SQLクエリのインデックスを追加する方法Apr 10, 2025 pm 12:15 PM

インデックス作成は、データ列を並べ替えてデータ検索を加速するデータ構造です。 SQLクエリにインデックスを追加する手順は次のとおりです。インデックス化する必要がある列を決定します。適切なインデックスタイプ（Bツリー、ハッシュ、またはビットマップ）を選択します。 Create Indexコマンドを使用して、インデックスを作成します。インデックスを定期的に再構築または再編成して、その効率を維持します。インデックスの追加の利点には、クエリパフォーマンスの改善、I/O操作の削減、最適化された並べ替えとフィルタリング、および並行性の改善が含まれます。クエリが特定の列を使用することが多い場合、ソートまたはグループ化する必要がある大量のデータを返し、大きい複数のテーブルまたはデータベーステーブルが含まれます。インデックスの追加を検討する必要があります。

SQLステートメントにIfelseの使用方法Apr 10, 2025 pm 12:12 PM

Ifelseステートメントは、条件付き評価結果に基づいて異なる値を返す条件付きステートメントです。その構文構造は次のとおりです。if（条件）then return_value_if_condition_is_true elsen return_value_if_condition_is_false end if;。

SQLデータベースエラーを表示する方法Apr 10, 2025 pm 12:09 PM

SQLデータベースエラーを表示する方法は次のとおりです。1。エラーメッセージを直接表示します。 2。エラーを表示し、警告コマンドを表示します。 3.エラーログにアクセスします。 4.エラーコードを使用して、エラーの原因を見つけます。 5.データベース接続とクエリ構文を確認します。 6.デバッグツールを使用します。

SQLを個別に使用する方法Apr 10, 2025 pm 12:06 PM

個別の演算子は、SQLクエリの重複行を除外し、一意の値のみを返すために使用されます。一意の値のリストを取得したり、一意の値の数を数えたり、グループと組み合わせて使用したりするなどのシナリオに適しています。

SQL候補キーを設定する方法Apr 10, 2025 pm 12:03 PM

SQLで候補キーを設定する方法：一意の識別列を決定します。主キーの制約を使用して主キーを作成します。一意の制約を使用して一意の制約を追加します。一意のインデックスを作成します。候補キーの設定により、データの整合性が確保され、クエリのパフォーマンスが向上し、データの複製が防止されます。

See all articles

ホットAIツール

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

脱衣画像を無料で

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

DVWA

Damn Vulnerable Web App (DVWA) は、非常に脆弱な PHP/MySQL Web アプリケーションです。その主な目的は、セキュリティ専門家が法的環境でスキルとツールをテストするのに役立ち、Web 開発者が Web アプリケーションを保護するプロセスをより深く理解できるようにし、教師/生徒が教室環境で Web アプリケーションを教え/学習できるようにすることです。安全。 DVWA の目標は、シンプルでわかりやすいインターフェイスを通じて、さまざまな難易度で最も一般的な Web 脆弱性のいくつかを実践することです。このソフトウェアは、