mongodb效能分析方法：explain()
mongodb 3.0之後，explain的返回與使用方法與之前版本有了很大的變化，介於3.0之後的優秀特色和我們目前所使用給的是3.0.7版本，本文僅針對mongodb 3.0+的explain進行討論。
3.0+的explain有三種模式，分別是：queryplanner、executionstats、allplan***ecution。現實開發中，常用的是executionstats模式。
explain()也接收不同的引數，通過設定不同引數我們可以檢視更詳細的查詢計畫：
所以：我們在查詢優化的時候，只需要關注queryplanner， executionstats即可，因為queryplanner為我們選擇出了winningplan， 而executionstats為我們統計了winningplan的所有關鍵資料。
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的返回中意義相同，故不在此贅述。
最為直觀explain返回值是executiontimemillis值，指的是我們這條語句的執行時間，這個值當然是希望越少越好。
其中有3個executiontimemillis，分別是：
executionstats.executiontimemillis
該query的整體查詢時間。
executionstats.executionstages.executiontimemillisestimate
該查詢根據index去檢索document獲得2001條資料的時間。
executionstats.executionstages.inputstage.executiontimemillisestimate
該查詢掃瞄2001行index所用時間。
這個主要討論3個返回項，nreturned、totalkey***amined、totaldoc***amined，分別代表該條查詢返回的條目、索引掃瞄條目、文件掃瞄條目。
這些都是直觀地影響到executiontimemillis，我們需要掃瞄的越少速度越快。
對於乙個查詢，我們最理想的狀態是：
nreturned=totalkey***amined=totaldoc***amined
那麼又是什麼影響到了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
collscan(全表掃瞄)
sort(使用sort但是無index)
不合理的skip
subpla(未用到index的$or)
countscan(不使用index進行count)
MySQL SQL執行計畫分析
當我們的系統上線後資料庫的記錄不斷增加，之前寫的一些sql語句或者一些orm操作效率變得非常低。我們不得不考慮sql優化，sql優化大概是這樣乙個流程 1.定位執行效率低的sql語句 定位 2.分析為什麼這段sql執行的效率比較低 分析 3.最後根據第二步分析的結構採取優化措施 解決 而explai...
MySQL執行計畫分析
原文 mysql執行計畫分析 sql執行計畫的輸出可能為多行，每一行代表對乙個資料庫物件的操作 可以看到上面的執行計畫返回了3行結果，id列的值可以看作是sql中所具有的select操作的序號 由於上述sql中只有乙個select，所以id全為1，因此，我們就要按照由上至下讀取執行計畫 按照我們的s...
mysql執行計畫分析
執行計畫是sql在資料庫中執行時的表現情況,通常用於sql效能分析,優化等場景。在mysql中使用 explain 關鍵字來檢視。如下所示 explain select from table where table.id 1執行上面的sql語句後你會看到，下面的表頭資訊 table type pos...