2. 程式人生 > >MongoDB 索引的最佳實踐

MongoDB 索引的最佳實踐

阿新 • • 發佈：2019-06-24

前言

大部分開發者都知道加索引會快。但實際過程中，我們常碰到一些疑問&困難：

  • 我們查詢的欄位會各種case都有，是不是各個涉及查詢的欄位都要加索引？
  • 複合索引和單欄位怎麼選擇，都加還是每一個的單個欄位就好了？
  • 加索引有沒有副作用？
  • 索引都加了，但還是不夠快？怎麼辦？

本文嘗試去解釋索引的基本知識&解答上述的疑問。

一、索引究竟是什麼東西？

大部分開發者接觸索引，大概知道索引類似書的目錄，你要找到想要的內容，通過目錄找到限定的關鍵字，進而找到對應的章節的pageno，再找到具體的內容。
在資料結構裡面，最簡單的索引實現類似hashmap，通過關鍵字key，對映到具體的位置，找到具體的內容。但除了hash的方式，還有多種的方式實現索引。

（一）索引的多種實現方式以及特色

hash / b-tree / b+-tree redis HSET / MongoDB&PostgreSQL / MySQL

hashmap

一圖見b-tree & b+-tree 差別：

  • b+-tree 葉子存資料，非葉子存索引，不存資料，葉子間有link
  • b-tree 非葉子可存資料

演算法查詢複雜度上來說：

  • hash 接近O(1)
  • b-tree O(1)~ O(Log(n))更快的平均查詢時間，不穩定的查詢時間
  • b+ tree O(Log(n)) 連續資料， 查詢的穩定性

至於為何MongoDB 的實現選擇b-tree 而非 b+-tree ？

網上多篇文章有闡述，非本文重點。

（二）資料&索引的儲存

index儘量儲存在記憶體，data 其次。
注意只保留必要的index，記憶體儘量用在刀刃上。
如果index memory 都接近佔滿memory，那麼就很容易讀到disk，速度就下來了。

（三）知道索引的實現&儲存原理後的思考

insert/update/delete 會觸發rebalance tree，所以，增刪改資料，索引會觸發修改，效能會有損耗，索引不是越多越好。既然如此，選哪些欄位作為索引呢？當查詢用到這些條件，怎麼辦？
拿一個最簡單的hashmap來講，為什麼複雜度不是O(1)，而是所謂接近 O(1)。因為有key 衝突/重複，DB 去找的時候，key 衝突的資料一大堆的話，還是得輪著繼續找。b-tree 看鍵(key)的選擇也是如此。

因此一個大部分開發經常犯的錯就是對沒有區分度的key建索引。例如：很多就只有集中類別的 type/status 的 documents count 達幾十萬以上的collection，通常這種索引沒什麼幫助。

二、複合索引

（一）複合索引不是越多越好

如果不想多建多餘的索引，開發的同事在複合 & 單個欄位選擇上有時候挺糾結的。 根據典型碰到的場景，來做幾個實驗：
這裡建立了個loans collection。簡化只有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 全表掃描了,因為沒有索引。接下來我們分別建立幾個索引。
step 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} 作為 winning plan。

step2：再建立個典型的索引 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
}

有趣的部分：status不命中索引，全表掃描
接下來的步驟，加個sort :


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
}

（二）其他嘗試

有趣的部分：status 不命中索引

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
}

命中索引，跟query的各個欄位順序不相關，如我們猜測。
有趣部分再來， 我們刪掉索引{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} 能更優,沒有命中複合索引，這個是因為status不是leading field。

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
}

再換個角度sort 一遍， 與前面query & sort互換，之前是：

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
}

如猜測，命中索引。
再來玩玩，確認下leading filed試驗：

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個問題沒回答：如果我的索引改加的都加了，還不夠快,怎麼辦？
留個懸念，

相關推薦

索引最佳實踐

create 設計 創建 函數 常見 end 由於 sql 階段 索引最佳實踐 在使用索引時，我們可以通過explain+extended查看SQL的執行計劃，判斷是否使用了索引以及發生了隱式轉換。 由於常見的隱式轉換是由字段數據類型以及collation定義不當導

MongoDB操作最佳實踐(二)

MongoDB部署前的準備   MongoDB可拔插儲存引擎 MongoDB公開了儲存引擎API，支援整合可插入儲存引擎，這些可插入儲存引擎使用新功能擴充套件MongoDB，並且支援優化使用指定的硬體體系結構。MongoDB 這艘船擁有多個支援的儲存引擎：  

MongoDB操作最佳實踐(一)

MongoDB 3.4 (ps：文章大部分內容都是藉助百度翻譯，然後在上面作一些修正的。翻譯不是目的，主要目的是強迫自己沉下心來將英文的技術文章看下去)   簡介 MongoDB是一種高效能、可擴充套件、分散式、為現代應用而設計的資料庫。它被各種大大小小的組織用來處理關鍵

MYSQL索引最佳實踐

你做了一個明智的選擇 理解索引對開發和dba來說都是極其重要 差勁的索引對產品問題負相當大的一部分責任 索引不是多麼高深的問題 MySQL 索引一覽表 理解索引 為你的應用建立最佳索引 擁抱MySQL的限制 簡述索引 索引有什麼用 為從資料庫讀取資料加

MongoDB操作最佳實踐(十)

  MongoDB Atlas：作為MongoDB服務的資料庫 MongoDB Atlas提供了MongoDB的所有特性，而無需任何新應用程式所需的操作繁重。MongoDB Atlas通過現收現付模式按需提供，並按小時計費，讓您專注於您最擅長的工作。 很容易開始——使用一個簡單

MongoDB操作最佳實踐(九)

  災難恢復：備份與恢復 備份和恢復策略對於保護任務關鍵型資料免受災難性故障或人為錯誤（例如程式碼錯誤或意外丟棄集合）是必需的。有了備份和恢復策略，管理員可以在沒有資料丟失的情況下恢復業務操作，並且組織可以滿足法規和遵從性要求。定期備份還有其他優點。備份可用於為開發、階段或QA部署

MongoDB操作最佳實踐(八)

管理MongoDB：準備、監視和災難恢復 Ops Manager是由開發資料庫的工程師建立的，是執行MongoDB的最簡單方法，使操作團隊易於部署、監視、備份和擴充套件MongoDB。Ops Manager的許多功能在託管在雲中的MongoDB Cloud Manager服務中也是可用的。今天，

MongoDB 索引的最佳實踐

前言 大部分開發者都知道加索引會快。但實際過程中，我們常碰到一些疑問&困難： 我們查詢的欄位會各種case都有，是不是各

MySQL性能優化的21個最佳實踐 和 mysql使用索引

oct 靜態 state zid 希望 lte 適合 實踐 打開 今天，數據庫的操作越來越成為整個應用的性能瓶頸了，這點對於Web應用尤其明顯。關於數據庫的性能，這並不只是DBA才需要擔心的事，而這更是我 們程序員需要去關註的事情。當我們去設計數據庫表結構，對操作數據庫時(

MongoDB 應用場景、避坑事項與最佳實踐

社群最近組織了交流活動，探討MongoDB適合的應用場景、避坑事項與最佳實踐。由社群專家劉誠傑根據交流內容整理成文，無論是MongoDB零基礎的小夥伴，還是正在應用中的朋友，在此均可以找到有價值的經驗和分享。 劉誠傑，專注於MongoDB、MySQL、Redis等開源資料庫的使用與研究，Mo

《TableStore最佳實踐：GEO索引打造店鋪搜尋系統》

一、方案背景對於一套GEO管理系統，其核心點與瓶頸在於資料庫的儲存效能與查詢能力；一方面，儲存服務需要應對海量資料的低延遲存、讀，另一方面，儲存服務也要提供高效的GEO+多維度資料檢索。表格儲存（TableStore），作為一款Serverless分散式NoSQL資料庫，完全具備該系統的需求。下面我們將基於T

TableStore最佳實踐：GEO索引打造店鋪搜尋系統

一、方案背景 對於一套GEO管理系統，其核心點與瓶頸在於資料庫的儲存效能與查詢能力；一方面，儲存服務需要應對海量資料的低延遲存、讀，另一方面，儲存服務也要提供高效的GEO+多維度資料檢索。表格儲存（TableStore），作為一款Serverless分散式NoSQL資料庫，完全具備該系統的

JSON資料從MongoDB遷移到MaxCompute最佳實踐

資料及賬號準備 首先您需要將資料上傳至您的MongoDB資料庫。本例中使用阿里雲的 雲資料庫 MongoDB 版，網路型別為VPC（需申請公網地址，否則無法與DataWorks預設資源組互通），測試資料如下。 { "store": {

《TableStore最佳實踐：GEO索引打造店鋪搜索系統》

proc 頁面 cto get arch pro 跳轉 數據表 產品 一、方案背景對於一套GEO管理系統，其核心點與瓶頸在於數據庫的存儲性能與查詢能力；一方面，存儲服務需要應對海量數據的低延遲存、讀，另一方面，存儲服務也要提供高效的GEO+多維度數據檢索。表格存儲（Tabl

JSON數據從MongoDB遷移到MaxCompute最佳實踐

語句 RoCE 雲數據 添加 pri ESS truncate sele steps 摘要： 本文為您介紹如何利用DataWorks數據集成直接從MongoDB提取JSON字段到MaxCompute。 數據及賬號準備首先您需要將數據上傳至您的MongoDB數據庫。本例中使用

MySQL · 最佳實踐 · 如何索引JSON欄位

概述 MySQL從5.7.8起開始支援JSON欄位，這極大的豐富了MySQL的資料型別。也方便了廣大開發人員。但MySQL並沒有提供對JSON物件中的欄位進行索引的功能，至少沒有直接對其欄位進行索引的方法。本文將介紹利用MySQL 5.7中的虛擬欄位的功能來對JSON物件中的欄位進行索引。

【轉】 MongoDB 應用場景、避坑事項與最佳實踐

  MongoDB 是一個高效能，開源，無模式的文件型資料庫，是當前 NoSQL 資料庫產品中最熱門的一種。它在許多場景下可用於替代傳統的關係型資料庫或鍵/值儲存方式，MongoDB 使用 C++開發。 為什麼要用 NoSQL NoSQL,全稱是”Not Only Sql”,指的

[重要] -- MySQL效能優化的21個最佳實踐 和 mysql使用索引

今天，資料庫的操作越來越成為整個應用的效能瓶頸了，這點對於Web應用尤其明顯。關於資料庫的效能，這並不只是DBA才需要擔心的事，而這更是我 們程式設計師需要去關注的事情。當我們去設計資料庫表結構，對操作資料庫時(尤其是查表時的SQL語句)，我們都需要注意資料操作的效

MySQL效能優化的21個最佳實踐 和 mysql使用索引

今天，資料庫的操作越來越成為整個應用的效能瓶頸了，這點對於Web應用尤其明顯。關於資料庫的效能，這並不只是DBA才需要擔心的事，而這更是我 們程式設計師需要去關注的事情。當我們去設計資料庫表結構，對操作資料庫時(尤其是查表時的SQL語句)，我們都需要注意資料操作的效能。這裡，我們不會講過 多的SQL語句的優

msql效能優化的21個最佳實踐和mysql索引的使用

今天，資料庫的操作越來越成為整個應用的效能瓶頸了，這點對於Web應用尤其明顯。關於資料庫的效能，這並不只是DBA才需要擔心的事，而這更是我 們程式設計師需要去關注的事情。當我們去設計資料庫表結構，對操作資料庫時(尤其是查表時的SQL語句)，我們都需要注意資料操作的效能。