當你抱怨mongodb集合查詢效率低的時候，可能你就需要考慮使用索引了，為了方便後續介紹，先科普下mongodb裡的索引機制（同樣適用於其他的資料庫比如mysql）。
mongo-9552:primary> db.person.find()
『檔案id + 檔案內offset 』， 在wiredtiger儲存引擎（乙個kv儲存引擎）裡，位置資訊是wiredtiger在儲存文件時生成的乙個key，通過這個key能訪問到對應的文件；為方便介紹，統一用pos(position的縮寫)來代表位置資訊。
比如上面的例子裡，person集合裡包含插入了4個文件，假設其儲存後位置資訊如下(為方便描述，文件省去_id欄位)
位置資訊
文件pos1
pos2
pos3
pos4
pos5
假設現在有個查詢db.person.find( ), 查詢所有年齡為18歲的人，這時需要遍歷所有的文件（『全表掃瞄』），根據位置資訊讀出文件，對比age欄位是否為18。當然如果只有4個文件，全表掃瞄的開銷並不大，但如果集合文件數量到百萬、甚至千萬上億的時候，對集合進行全表掃瞄開銷是非常大的，乙個查詢耗費數十秒甚至幾分鐘都有可能。
如果想加速db.person.find( ），就可以考慮對person表的age欄位建立索引。
db.person.createindex( ) // 按age欄位建立公升序索引o(logn)的時間複雜度）找出某個age值對應的位置資訊，然後根據位置資訊就能讀取出對應的文件。
age位置資訊
18pos3
18pos5
19pos1
20pos2
21pos4
簡單的說，索引就是將文件按照某個（或某些）字段順序組織起來，以便能根據該欄位高效的查詢。有了索引，至少能優化如下場景的效率：
眾所周知，mongodb缺省會為插入的文件生成_id欄位（如果應用本身沒有指定該欄位），_id是文件唯一的標識，為了保證能根據文件id快遞查詢文件，mongodb缺省會為集合建立_id欄位的索引。
mongo-9552:primary> db.person.getindexes() // 查詢集合的索引資訊
[ ,
"name" : "_id_" // 索引的名稱
}]
db.person.createindex( )代表公升序索引，也可以通過來指定降序索引，對於單字段索引，公升序/降序效果是一樣的。
復合索引是single field index的公升級版本，它針對多個字段聯合建立索引，先按第乙個字段排序，第乙個字段相同的文件按第二個字段排序，依次類推，如下針對age, name這2個字段建立乙個復合索引。
db.person.createindex( )age,name
位置資訊
18,adam
pos5
18,jack
pos3
19,jack
pos1
20,rose
pos2
21,tony
pos4
復合索引能滿足的查詢場景比單字段索引更豐富，不光能滿足多個字段組合起來的查詢，比如db.person.find( )，也能滿足所以能匹配符合索引字首的查詢，這裡即為的字首，所以類似db.person.find( )的查詢也能通過該索引來加速；但db.person.find( )則無法使用該復合索引。如果經常需要根據『name欄位』以及『name和age欄位組合』來查詢，則應該建立如下的復合索引
db.person.createindex( )age欄位的取值很有限，即擁有相同age欄位的文件會有很多；而name欄位的取值則豐富很多，擁有相同name欄位的文件很少；顯然先按name欄位查詢，再在相同name的文件裡查詢age欄位更為高效。
當索引的字段為陣列時，建立出的索引稱為多key索引，多key索引會為陣列的每個元素建立一條索引，比如person表加入乙個habbit欄位（陣列）用於描述興趣愛好，需要查詢有相同興趣愛好的人就可以利用habbit欄位的多key索引。
db.person.createindex( ) // 自動建立多key索引
db.person.find( )
地理位置索引（geospatial index）能很好的解決o2o的應用場景，比如『查詢附近的美食』、『查詢某個區域內的車站』等。
文字索引（text index）能解決快速文字查詢的需求，比如有乙個部落格文章集合，需要根據部落格的內容來快速查詢，則可以針對部落格內容建立文字索引。
mongodb除了支援多種不同型別的索引，還能對索引定製一些特殊的屬性。
mongodb支援對db的請求進行profiling，目前支援3種級別的profiling。
通常，生產環境建議使用1級別的profiling，並根據自身需求配置合理的閾值，用於監測慢請求的情況，並及時的做索引優化。
如果能在集合建立的時候就能『根據業務查詢需求決定應該建立哪些索引』，當然是最佳的選擇；但由於業務需求多變，要根據實際情況不斷的進行優化。索引並不是越多越好，集合的索引太多，會影響寫入、更新的效能，每次寫入都需要更新所有索引的資料；所以你system.profile裡的慢請求可能是索引建立的不夠導致，也可能是索引過多導致。
索引已經建立了，但查詢還是很慢怎麼破？這時就得深入的分析下索引的使用情況了，可通過檢視下詳細的查詢計畫來決定如何優化。通過執行計畫可以看出如下問題
根據某個/些字段查詢，但沒有建立索引
根據某個/些字段查詢，但建立了多個索引，執行查詢時沒有使用預期的索引。
建立索引前，db.person.find( )必須執行collscan，即全表掃瞄。
mongo-9552:primary> db.person.find().explain()
},"winningplan" :
},"direction" : "forward"
},"rejectedplans" : [ ]
},"serverinfo" : ,
"ok" : 1
}
mongo-9552:primary> db.person.find().explain()
},"winningplan" : ,
"indexname" : "age_1",
"ismultikey" : false,
"isunique" : false,
"issparse" : false,
"ispartial" : false,
"indexversion" : 1,
"direction" : "forward",
"indexbounds" : }},
"rejectedplans" : [ ]
},"serverinfo" : ,
"ok" : 1
}
MongoDB索引原理
當你抱怨mongodb集合查詢效率低的時候，可能你就需要考慮使用索引了，為了方便後續介紹，先科普下mongodb裡的索引機制 同樣適用於其他的資料庫比如mysql mongo 9552 primary db.person.find 當你往某各個集合插入多個文件後，每個文件在經過底層的儲存引擎持久化後...
MongoDB索引原理
當你抱怨mongodb集合查詢效率低的時候，可能你就需要考慮使用索引了，為了方便後續介紹，先科普下mongodb裡的索引機制 同樣適用於其他的資料庫比如mysql mongo 9552 primary db.person.find 當你往某各個集合插入多個文件後，每個文件在經過底層的儲存引擎持久化後...
MongoDB 特性分析 索引原理
當你抱怨mongodb集合查詢效率低的時候，可能你就需要考慮使用索引了，為了方便後續介紹，先科普下mongodb裡的索引機制 同樣適用於其他的資料庫比如mysql mongo 9552 primary db.person.find 當你往某各個集合插入多個文件後，每個文件在經過底層的儲存引擎持久化後...