當你抱怨mongodb集合查詢效率低的時候，可能你就需要考慮使用索引了，為了方便後續介紹，先科普下mongodb裡的索引機制（同樣適用於其他的資料庫比如mysql）。
mongo-9552:primary> db.person.find()
當你往某各個集合插入多個文件後，每個文件在經過底層的儲存引擎持久化後，會有乙個位置資訊，通過這個位置資訊，就能從儲存引擎裡讀出該文件。比如mmapv1引擎裡，位置資訊是『檔案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欄位建立公升序索引
建立索引後，mongodb會額外儲存乙份按age欄位公升序排序的索引資料，索引結構類似如下，索引通常採用類似btree的結構持久化儲存，以保證從索引裡快速（o(logn)的時間複雜度）找出某個age值對應的位置資訊，然後根據位置資訊就能讀取出對應的文件。
age位置資訊
18pos3
18pos5
19pos1
20pos2
21pos4
簡單的說，索引就是將文件按照某個（或某些）字段順序組織起來，以便能根據該欄位高效的查詢。有了索引，至少能優化如下場景的效率：
眾所周知，mongodb缺省會為插入的文件生成_id欄位（如果應用本身沒有指定該欄位），_id是文件唯一的標識，為了保證能根據文件id快遞查詢文件，mongodb缺省會為集合建立_id欄位的索引。
mongo-9552:primary> db.person.getindexes() //查詢集合的索引資訊
[ ,
"name" : "_id_" //
索引的名稱
}]
mongodb支援多種型別的索引，包括單字段索引、復合索引、多key索引、文字索引等，每種型別的索引有不同的使用場合。
db.person.createindex( )
上述索引對應的資料組織類似下表，與索引不同的時，當age欄位相同時，在根據name欄位進行排序，所以pos5對應的文件排在pos3之前。
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( )
除了查詢的需求能夠影響索引的順序，欄位的值分布也是乙個重要的考量因素，即使person集合所有的查詢都是『name和age欄位組合』（指定特定的name和age），欄位的順序也是有影響的。
age欄位的取值很有限，即擁有相同age欄位的文件會有很多；而name欄位的取值則豐富很多，擁有相同name欄位的文件很少；顯然先按name欄位查詢，再在相同name的文件裡查詢age欄位更為高效。
當索引的字段為陣列時，建立出的索引稱為多key索引，多key索引會為陣列的每個元素建立一條索引，比如person表加入乙個habbit欄位（陣列）用於描述興趣愛好，需要查詢有相同興趣愛好的人就可以利用habbit欄位的多key索引。
db.person.createindex( ) //
自動建立多key索引
db.person.find( )
雜湊索引（hashed index）是指按照某個欄位的hash值來建立索引，目前主要用於mongodb sharded cluster的hash分片，hash索引只能滿足字段完全匹配的查詢，不能滿足範圍查詢等。
地理位置索引（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}
建立索引後，通過查詢計畫可以看出，先進行[ixscan]((從索引中查詢)，然後fetch，讀取出滿足條件的文件。
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 當你往某各個集合插入多個文件後，每個文件在經過底層的儲存引擎持久化後...