mongodb效能分析方法：explain()
為了演示的效果，我們先來建立乙個有200萬個文件的記錄。（我自己的電腦耗了15分鐘左右插入完成。如果你想插更多的文件也沒問題，只要有耐心等就可以了。）
mongodb 3.0之後，explain的返回與使用方法與之前版本有了很大的變化，介於3.0之後的優秀特色和我們目前所使用給的是3.0.7版本，本文僅針對mongodb 3.0+的explain進行討論。3.0+的explain有三種模式，分別是：queryplanner、executionstats、allplan***ecution。現實開發中，常用的是executionstats模式，主要分析這種模式。
給這個person集合建立age鍵的索引：db.person.createindex()
1db.getcollection('person').find(}).explain("executionstats")10 },
11 "winningplan" : ,
18 "indexname" : "age_1",
19 "ismultikey" : false,
20 "direction" : "forward",
21 "indexbounds" :
26 }
27 },
28 "rejectedplans" :
29 },
30 "executionstats" : ,
65 "indexname" : "age_1",
66 "ismultikey" : false,
67 "direction" : "forward",
68 "indexbounds" : ,
73 "key***amined" : 2001,
74 "dupstested" : 0,
75 "dupsdropped" : 0,
76 "seeninvalidated" : 0,
77 "matchtested" : 0
78 }
79 }
80 },
81 "serverinfo" : ,
87 "ok" : 1.0
88 }
對queryplanner分析
queryplanner: queryplanner的返回
queryplanner.namespace:該值返回的是該query所查詢的表
queryplanner.indexfilterset:針對該query是否有indexfilter
queryplanner.winningplan:查詢優化器針對該query所返回的最優執行計畫的詳細內容。
queryplanner.winningplan.stage:最優執行計畫的stage，這裡返回是fetch，可以理解為通過返回的index位置去檢索具體的文件（stage有數個模式，將在後文中進行詳解）。
queryplanner.winningplan.inputstage:用來描述子stage，並且為其父stage提供文件和索引關鍵字。
queryplanner.winningplan.stage的child stage，此處是ixscan，表示進行的是index scanning。
queryplanner.winningplan.keypattern:所掃瞄的index內容，此處是did:1,status:1,modify_time: -1與scid : 1
queryplanner.winningplan.indexname：winning plan所選用的index。
queryplanner.winningplan.ismultikey是否是multikey，此處返回是false，如果索引建立在array上，此處將是true。
queryplanner.winningplan.direction：此query的查詢順序，此處是forward，如果用了.sort()將顯示backward。
queryplanner.winningplan.indexbounds:winningplan所掃瞄的索引範圍,如果沒有制定範圍就是[maxkey, minkey]，這主要是直接定位到mongodb的chunck中去查詢資料，加快資料讀取。
queryplanner.rejectedplans：其他執行計畫（非最優而被查詢優化器reject的）的詳細返回，其中具體資訊與winningplan的返回中意義相同，故不在此贅述。
對executionstats返回逐層分析
第一層，executiontimemillis
最為直觀explain返回值是executiontimemillis值，指的是我們這條語句的執行時間，這個值當然是希望越少越好。
其中有3個executiontimemillis，分別是：
executionstats.executiontimemillis
該query的整體查詢時間。
executionstats.executionstages.executiontimemillisestimate
該查詢根據index去檢索document獲得2001條資料的時間。
executionstats.executionstages.inputstage.executiontimemillisestimate
該查詢掃瞄2001行index所用時間。
第二層，index與document掃瞄數與查詢返回條目數
這個主要討論3個返回項，nreturned、totalkey***amined、totaldoc***amined，分別代表該條查詢返回的條目、索引掃瞄條目、文件掃瞄條目。
這些都是直觀地影響到executiontimemillis，我們需要掃瞄的越少速度越快。
對於乙個查詢，我們最理想的狀態是：
nreturned=totalkey***amined=totaldoc***amined
第三層，stage狀態分析
那麼又是什麼影響到了totalkey***amined和totaldoc***amined？是stage的型別。型別列舉如下：
collscan：全表掃瞄
ixscan：索引掃瞄
fetch：根據索引去檢索指定document
shard_merge：將各個分片返回資料進行merge
sort：表明在記憶體中進行了排序
limit：使用limit限制返回數
skip：使用skip進行跳過
idhack：針對_id進行查詢
sharding_filter：通過mongos對分片資料進行查詢
count：利用db.coll.explain().count()之類進行count運算
countscan：count不使用index進行count時的stage返回
count_scan：count使用了index進行count時的stage返回
subpla：未使用到索引的$or查詢的stage返回
text：使用全文索引進行查詢時候的stage返回
projection：限定返回字段時候stage的返回
對於普通查詢，我希望看到stage的組合(查詢的時候盡可能用上索引)：
fetch+idhack
fetch+ixscan
limit+（fetch+ixscan）
projection+ixscan
sharding_fiter+ixscan
count_scan
不希望看到包含如下的stage：
collscan(全表掃瞄),sort(使用sort但是無index),不合理的skip,subpla(未用到index的$or),countscan(不使用index進行count)
**
MongoDB查詢效能分析
explain 方法能夠提供大量與查詢相關的資訊。對於速度比較慢的查詢來說，它是最重要的效能分析工具之一。通過檢視乙個查詢的explain 輸出資訊，可以知道查詢使用了哪個索引，以及是如何使用的。對於任意查詢，都可以在最後新增乙個explain 呼叫 與呼叫sort 或者limit 一樣，不過exp...
提公升MongoDB效能的方法
mongodb 是高效能資料，但是在使用的過程中，大家偶爾還會碰到一些效能問題。mongodb和其它關係型資料庫相比，例如 sql server mysql oracle 相比來說，相對較新，很多人對其不是很熟悉，所以很多開發 dba往往是注重功能的實現，而忽視了效能的要求。其實，mongodb和 ...
MongoDB資料庫效能分析
設定當前資料庫日誌級別 db.setprofilinglevel n 引用n 0 關閉效能分析，測試環境可以開啟，生成環境關閉，對效能有很大影響 1 開啟慢查詢日誌，執行時間大於100毫秒的語句 2 開啟所有操作日誌 獲取當前資料庫日誌分析級別 db.getprofilinglevel 資料庫的日誌...