mongodb 3.0之後,explain的返回與使用方法與之前版本有了不少變化,介於3.0之後的優秀特色,本文僅針對mongodb 3.0+的explain進行討論。
現版本explain有三種模式,分別如下:
其中 queryplanner 是現版本explain的預設模式,queryplanner模式下並不會去真正進行query語句查詢,而是針對query語句進行執行計畫分析並選出winning plan。
舉個執行計畫的命令例子:
db.usertable.find().explain("queryplanner")
舉個執行計畫響應結果的例子:
},"winningplan":,
"indexname":"w_1_n_1", #winning plan所選用的index。
"ismultikey":false, #本次查詢是否使用了多鍵、復合索引
"direction":"forward", #此query的查詢順序,此處是forward,如果用了.sort()將顯示backward。
"indexbounds":}},
"rejectedplans":[ #其他執行計畫(非最優而被查詢優化器reject的)的詳細返回,其中具體資訊與winningplan的返回中意義相同,故不在此贅述。
,"indexname":"w_1_v_1",
"ismultikey":false,
"direction":"forward",
"indexbounds":}}
]},
"serverinfo" : ,
"ok" : 1
}
如explain.queryplanner.winningplan.stageexplain.queryplanner.winningplan.inputstage**等。
stage/inputstage值
值的意義
collscan
全表掃瞄
ixscan
索引掃瞄
fetch
根據索引去檢索指定document
shard_merge
將各個分片返回資料進行merge
sort
表明在記憶體中進行了排序(與老版本的scanandorder:true一致)
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的返回
執行一:
db.usertable.find().explain("queryplanner")
},"direction" : "forward"
},...
}
執行二:
db.usertable.find().limit(1).explain("queryplanner")
},"direction" : "forward"}},
...}
執行二在執行一的基礎上增加了 limit限掉, queryplanner由 stage(collscan) 變成了 stage(limit)、inputstage.stage(collscan)。說明在判斷queryplanner是否達到使用者想要的效果要對 stageinputstage.stag綜合考慮。 高效能mongodb之執行計畫
mongodb 3.0之後,explain的返回與使用方法與之前版本有了不少變化,介於3.0之後的優秀特色,本文僅針對mongodb 3.0 的explain進行討論。現版本explain有三種模式,分別如下 其中 queryplanner 是現版本explain的預設模式,queryplanner...
高效能sql優化 執行計畫
一 序言 執行計畫是sql調優必不可少的一部分,如果你還是簡單的認為我們向資料庫發出一條sql語句,資料庫只是根據我們的需求解析sql語句,然後返回我們想要的結果,那你真的是太天真了,因為資料庫還會對每條通過會話發出的sql進行一系列的檢查 分析和處理,然後由優化器選擇生成護著選定出乙個成本最低的執...
MongoDB檢視執行計畫
一 概述 mongodb中的explain 函式可以幫助我們檢視查詢相關的資訊,查詢分析可以確保我們建立的索引是否有效,是查詢語句效能分析的重要工具。二 explain 基本用法 explain 的用法是必須放在最後面,語法如下 db.collecton.find explain explain 常...