為什麼需要索引？
當你抱怨MongoDB集合查詢效率低的時候，可能你就需要考慮使用索引了，為了友善後續介紹，先科普下MongoDB裡的索引機制（同樣适用于其他的資料庫比如mysql）。
mongo-9552:PRIMARY> db.person.find()
{ "_id" : ObjectId("571b5da31b0d530a03b3ce82"), "name" : "jack", "age" : 19 }
{ "_id" : ObjectId("571b5dae1b0d530a03b3ce83"), "name" : "rose", "age" : 20 }
{ "_id" : ObjectId("571b5db81b0d530a03b3ce84"), "name" : "jack", "age" : 18 }
{ "_id" : ObjectId("571b5dc21b0d530a03b3ce85"), "name" : "tony", "age" : 21 }
{ "_id" : ObjectId("571b5dc21b0d530a03b3ce86"), "name" : "adam", "age" : 18 }
當你往某各個集合插入多個文檔後，每個文檔在經過底層的存儲引擎持久化後，會有一個位置資訊，通過這個位置資訊，就能從存儲引擎裡讀出該文檔。比如
mmapv1引擎裡，位置資訊是
『檔案id + 檔案内offset 』
， 在
wiredtiger存儲引擎（一個KV存儲引擎）裡，位置資訊是wiredtiger在存儲文檔時生成的一個key，通過這個key能通路到對應的文檔；為友善介紹，統一用
pos(position的縮寫)
來代表位置資訊。
比如上面的例子裡，
person
集合裡包含插入了4個文檔，假設其存儲後位置資訊如下(為友善描述，文檔省去_id字段)
| 位置資訊 | 文檔 |
|---|---|
| pos1 | {“name” : “jack”, “age” : 19 } |
| pos2 | {“name” : “rose”, “age” : 20 } |
| pos3 | {“name” : “jack”, “age” : 18 } |
| pos4 | {“name” : “tony”, “age” : 21} |
| pos5 | {“name” : “adam”, “age” : 18} |
假設現在有個查詢
db.person.find( {age: 18} )
, 查詢所有年齡為18歲的人，這時需要周遊所有的文檔（『全表掃描』），根據位置資訊讀出文檔，對比age字段是否為18。當然如果隻有4個文檔，全表掃描的開銷并不大，但如果集合文檔數量到百萬、甚至千萬上億的時候，對集合進行全表掃描開銷是非常大的，一個查詢耗費數十秒甚至幾分鐘都有可能。
如果想加速
db.person.find( {age: 18} ）
，就可以考慮對person表的age字段
建立索引。
db.person.createIndex( {age: 1} ) // 按age字段建立升序索引
建立索引後，MongoDB會額外存儲一份按age字段升序排序的索引資料，索引結構類似如下，索引通常采用類似btree的結構持久化存儲，以保證從索引裡快速（
O(logN)的時間複雜度
）找出某個age值對應的位置資訊，然後根據位置資訊就能讀取出對應的文檔。
| age | |
|---|---|
| 18 | |
| 19 | |
| 20 | |
| 21 |
簡單的說，索引就是将
文檔
按照某個（或某些）字段順序組織起來，以便能根據該字段高效的查詢。有了索引，至少能優化如下場景的效率：
- 查詢，比如查詢年齡為18的所有人
- 更新/删除，将年齡為18的所有人的資訊更新或删除，因為更新或删除時，需要根據條件先查詢出所有符合條件的文檔，是以本質上還是在優化查詢
- 排序，将所有人的資訊按年齡排序，如果沒有索引，需要全表掃描文檔，然後再對掃描的結果進行排序
衆所周知，MongoDB預設會為插入的文檔生成_id字段（如果應用本身沒有指定該字段），_id是文檔唯一的辨別，為了保證能根據文檔id快遞查詢文檔，MongoDB預設會為集合建立_id字段的索引。
mongo-9552:PRIMARY> db.person.getIndexes() // 查詢集合的索引資訊
[
{
"ns" : "test.person", // 集合名
"v" : 1, // 索引版本
"key" : { // 索引的字段及排序方向
"_id" : 1 // 根據_id字段升序索引
},
"name" : "_id_" // 索引的名稱
}
]
MongoDB索引類型
MongoDB支援多種類型的索引，包括單字段索引、複合索引、多key索引、文本索引等，每種類型的索引有不同的使用場合。
單字段索引 （Single Field Index）
db.person.createIndex( {age: 1} )
上述語句針對age建立了單字段索引，其能加速對age字段的各種查詢請求，是最常見的索引形式，MongoDB預設建立的id索引也是這種類型。
{age: 1} 代表升序索引，也可以通過{age: -1}來指定降序索引，對于單字段索引，升序/降序效果是一樣的。
複合索引 (Compound Index)
複合索引是Single Field Index的更新版本，它針對多個字段聯合建立索引，先按第一個字段排序，第一個字段相同的文檔按第二個字段排序，依次類推，如下針對age, name這2個字段建立一個複合索引。
db.person.createIndex( {age: 1, name: 1} )
上述索引對應的資料組織類似下表，與{age: 1}索引不同的時，當age字段相同時，在根據name字段進行排序，是以pos5對應的文檔排在pos3之前。
| age,name | |
|---|---|
| 18,adam | |
| 18,jack | |
| 19,jack | |
| 20,rose | |
| 21,tony |
複合索引能滿足的查詢場景比單字段索引更豐富，不光能滿足多個字段組合起來的查詢，比如
db.person.find( {age： 18， name: "jack"} )
，也能滿足是以能比對符合索引字首的查詢，這裡{age: 1}即為{age: 1, name: 1}的字首，是以類似
db.person.find( {age： 18} )
的查詢也能通過該索引來加速；但
db.person.find( {name: "jack"} )
則無法使用該複合索引。如果經常需要根據『name字段』以及『name和age字段組合』來查詢，則應該建立如下的複合索引
db.person.createIndex( {name: 1, age: 1} )
除了查詢的需求能夠影響索引的順序，字段的值分布也是一個重要的考量因素，即使person集合所有的查詢都是『name和age字段組合』（指定特定的name和age），字段的順序也是有影響的。
age字段的取值很有限，即擁有相同age字段的文檔會有很多；而name字段的取值則豐富很多，擁有相同name字段的文檔很少；顯然先按name字段查找，再在相同name的文檔裡查找age字段更為高效。
多key索引 （Multikey Index）
當索引的字段為數組時，建立出的索引稱為多key索引，多key索引會為數組的每個元素建立一條索引，比如person表加入一個habbit字段（數組）用于描述興趣愛好，需要查詢有相同興趣愛好的人就可以利用habbit字段的多key索引。
{"name" : "jack", "age" : 19, habbit: ["football, runnning"]}
db.person.createIndex( {habbit: 1} ) // 自動建立多key索引
db.person.find( {habbit: "football"} )
其他類型索引
哈希索引（Hashed Index）是指按照某個字段的hash值來建立索引，目前主要用于
MongoDB Sharded Cluster的Hash分片，hash索引隻能滿足字段完全比對的查詢，不能滿足範圍查詢等。
地理位置索引（Geospatial Index）能很好的解決O2O的應用場景，比如『查找附近的美食』、『查找某個區域内的車站』等。
文本索引（Text Index）能解決快速文本查找的需求，比如有一個部落格文章集合，需要根據部落格的内容來快速查找，則可以針對部落格内容建立文本索引。
索引額外屬性
MongoDB除了支援多種不同類型的索引，還能對索引定制一些特殊的屬性。
- 唯一索引 (unique index) ：保證索引對應的字段不會出現相同的值，比如_id索引就是唯一索引
- TTL索引 ：可以針對某個時間字段，指定文檔的過期時間（經過指定時間後過期 或 在某個時間點過期）
- 部分索引 (partial index) : 隻針對符合某個特定條件的文檔建立索引，3.2版本才支援該特性
- 稀疏索引(sparse index) : 隻針對存在索引字段的文檔建立索引，可看做是部分索引的一種特殊情況
索引優化
db profiling
MongoDB支援對DB的請求進行
profiling，目前支援3種級别的profiling。
- 0： 不開啟profiling
- 1： 将處理時間超過某個門檻值(預設100ms)的請求都記錄到DB下的system.profile集合 （類似于mysql、redis的slowlog）
- 2： 将所有的請求都記錄到DB下的system.profile集合（生産環境慎用）
通常，生産環境建議使用1級别的profiling，并根據自身需求配置合理的門檻值，用于監測慢請求的情況，并及時的做索引優化。
如果能在集合建立的時候就能『根據業務查詢需求決定應該建立哪些索引』，當然是最佳的選擇；但由于業務需求多變，要根據實際情況不斷的進行優化。索引并不是越多越好，集合的索引太多，會影響寫入、更新的性能，每次寫入都需要更新所有索引的資料；是以你system.profile裡的慢請求可能是索引建立的不夠導緻，也可能是索引過多導緻。
查詢計劃
索引已經建立了，但查詢還是很慢怎麼破？這時就得深入的分析下索引的使用情況了，可通過檢視下詳細的
來決定如何優化。通過執行計劃可以看出如下問題
- 根據某個/些字段查詢，但沒有建立索引
- 根據某個/些字段查詢，但建立了多個索引，執行查詢時沒有使用預期的索引。
建立索引前，
db.person.find( {age： 18} )
必須執行
COLLSCAN，即全表掃描。
mongo-9552:PRIMARY> db.person.find({age: 18}).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "test.person",
"indexFilterSet" : false,
"parsedQuery" : {
"age" : {
"$eq" : 18
}
},
"winningPlan" : {
"stage" : "COLLSCAN",
"filter" : {
"age" : {
"$eq" : 18
}
},
"direction" : "forward"
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "localhost",
"port" : 9552,
"version" : "3.2.3",
"gitVersion" : "b326ba837cf6f49d65c2f85e1b70f6f31ece7937"
},
"ok" : 1
}
建立索引後，通過查詢計劃可以看出，先進行[IXSCAN]((https://docs.mongodb.org/manual/reference/explain-results/#queryplanner)(從索引中查找)，然後
FETCH，讀取出滿足條件的文檔。
mongo-9552:PRIMARY> db.person.find({age: 18}).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "test.person",
"indexFilterSet" : false,
"parsedQuery" : {
"age" : {
"$eq" : 18
}
},
"winningPlan" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"age" : 1
},
"indexName" : "age_1",
"isMultiKey" : false,
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 1,
"direction" : "forward",
"indexBounds" : {
"age" : [
"[18.0, 18.0]"
]
}
}
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "localhost",
"port" : 9552,
"version" : "3.2.3",
"gitVersion" : "b326ba837cf6f49d65c2f85e1b70f6f31ece7937"
},
"ok" : 1
}
![資料庫設計理論及應用（4）——概念結構設計1．概念模型 2．銷售子系統的分E-R圖 3．視圖的內建 4．設計基本E-R圖[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)