摘要:整體來說,通過查看執(zhí)行計劃,分析查詢性能情況,可以幫助我們更好的分析和優(yōu)化,必要的時候可以創(chuàng)建索引,提升查詢性能。
一、概述
MongoDB中的explain()函數(shù)可以幫助我們查看查詢相關(guān)的信息,查詢分析可以確保我們創(chuàng)建的索引是否有效,是查詢語句性能分析的重要工具。
二、explain()基本用法
explain()的用法是必須放在最后面,語法如下:
db.collecton.find({x:1}).explain()
explain()常用是直接跟在find()函數(shù)后面,表示查看find()函數(shù)的執(zhí)行計劃,舉例:
MongoDB Enterprise mongos> db.emp.find({"id":{$lt:1000}}).explain() { "queryPlanner" : { serverInfo" : { "host" : "mongotest1", "port" : 27021, "version" : "3.2.8", "gitVersion" : "ed70e33130c977bda0024c125b56d159573dbaf0" }, "plannerVersion" : 1, "namespace" : "testdb.emp", "indexFilterSet" : false, "parsedQuery" : { "id" : { "$lt" : 1000 } }, winningPlan" : { "stage" : "FETCH", "inputStage" : { "stage" : "SHARDING_FILTER", "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "id" : 1 }, "indexName" : "id_1", "direction" : "forward", }, "rejectedPlans" : [ ] }, "ok" : 1 }
參數(shù)說明:
以上我們看到的是explain()默認(rèn)參數(shù)的情況,其實(shí)MongoDB 3.0之后,explain的返回與使用方法與之前版本有了很大的變化,
3.0+版本的explain有三種模式,分別是:queryPlanner、executionStats、allPlansExecution。常用的是queryPlanner和executionStats模式
那我們再來看看executionStats這種模式
MongoDB Enterprise mongos> db.emp.find({"id":{$lt:1000}}).explain("executionStats") { "queryPlanner" : { "mongosPlannerVersion" : 1, "winningPlan" : { "stage" : "SHARD_MERGE", }, "rejectedPlans" : [ ] }, "executionStats" : { "nReturned" : 999, "executionTimeMillis" : 35, "totalKeysExamined" : 999, "totalDocsExamined" : 999, "executionStages" : { "stage" : "SHARD_MERGE", "nReturned" : 999, "executionTimeMillis" : 35, "totalKeysExamined" : 999, "totalDocsExamined" : 999, "totalChildMillis" : NumberLong(33), "shards" : [ { "shardName" : "shard1", "executionSuccess" : true, "executionStages" : { "stage" : "FETCH", "nReturned" : 980, "executionTimeMillisEstimate" : 30, "works" : 981, "advanced" : 980, "needTime" : 0, "needYield" : 0, "saveState" : 7, "restoreState" : 7, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 980, "alreadyHasObj" : 0 }, "ok" : 1 }
executionStats的參數(shù)說明:
在此看來,executionStats這種模式比默認(rèn)的queryPlanner給出來個更多的可參考的信息,
另外一種模式allPlansExecution是用來獲取所有執(zhí)行計劃,參數(shù)基本與以上的相同,這里就不再詳細(xì)說明。
三、總結(jié)
原來explain()也是可以接收不同的參數(shù),通過設(shè)置不同參數(shù)我們可以查看更詳細(xì)的查詢計劃。
queryPlanner:查詢計劃的選擇器,首先進(jìn)行查詢分析,最終選擇一個winningPlan,是explain返回的默認(rèn)模式
executionStats:為執(zhí)行統(tǒng)計模式,返回winningPlan的統(tǒng)計結(jié)果
allPlansExecution:為返回所有執(zhí)行計劃的統(tǒng)計,包括rejectedPlan
所以:我們在查詢優(yōu)化的時候,只需要關(guān)注queryPlanner, executionStats即可,因?yàn)閝ueryPlanner為我們選擇出了winningPlan, 而executionStats為我們統(tǒng)計了winningPlan的所有關(guān)鍵數(shù)據(jù)。
整體來說,通過explain()查看執(zhí)行計劃,分析查詢性能情況,可以幫助我們更好的分析和優(yōu)化,必要的時候可以創(chuàng)建索引,提升查詢性能。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/19402.html
摘要:優(yōu)志愿張海鵬宋體背景宋體每年月下旬到月下旬期間是高考填志愿的高峰期,也是優(yōu)志愿后端面臨大流量高并發(fā)請求的業(yè)務(wù)高峰期。對于優(yōu)志愿讀多寫少的場景及其業(yè)務(wù)高峰期,用戶可以按需增刪節(jié)點(diǎn),更好地實(shí)現(xiàn)讀取性能的擴(kuò)展。 隨著用戶規(guī)模的增長,數(shù)據(jù)庫的壓力也在成倍增加。面對大流量、高并發(fā),UCloud MongoDB 做到了高效,并展現(xiàn)出了更好的性能體驗(yàn)。 —— 優(yōu)志愿 CTO 張海鵬 背景...
摘要:表示本次查詢使用了索引,具體來說,是使用了和上的索引,。建立索引時,或者是每執(zhí)行次查詢之后,查詢優(yōu)化器都會重新評估查詢計劃。上一篇文章指南使用復(fù)合索引操作符如何使用索引索引對象和數(shù)組索引基數(shù)下一篇文章指南索引類型 上一篇文章:MongoDB指南---11、使用復(fù)合索引、$操作符如何使用索引、索引對象和數(shù)組、索引基數(shù)下一篇文章:MongoDB指南---13、索引類型 使用explain...
摘要:表示本次查詢使用了索引,具體來說,是使用了和上的索引,。建立索引時,或者是每執(zhí)行次查詢之后,查詢優(yōu)化器都會重新評估查詢計劃。上一篇文章指南使用復(fù)合索引操作符如何使用索引索引對象和數(shù)組索引基數(shù)下一篇文章指南索引類型 上一篇文章:MongoDB指南---11、使用復(fù)合索引、$操作符如何使用索引、索引對象和數(shù)組、索引基數(shù)下一篇文章:MongoDB指南---13、索引類型 使用explain...
摘要:所以在掃描次后,率先到達(dá)狀態(tài),那么此刻將停止掃描,進(jìn)入到算分的階段。除了這條引發(fā)故障的之外,其他的字段命中索引數(shù)量都非常小,有的甚至只有一條。那這里很明顯在中只去根據(jù)中執(zhí)行計劃的相關(guān)索引來進(jìn)行判斷是不合理的。 前段時間筆者遇到一個MongoBD Plan Cache的bug,于是深究了下MongoDB優(yōu)化器相關(guān)源碼。在這里分享給大家,一方面讓大家知道MongoDB優(yōu)化器工作原理,一方面...
閱讀 1458·2021-09-22 16:04
閱讀 2809·2019-08-30 15:44
閱讀 896·2019-08-30 15:43
閱讀 776·2019-08-29 15:24
閱讀 1857·2019-08-29 14:07
閱讀 1146·2019-08-29 12:30
閱讀 1741·2019-08-29 11:15
閱讀 2751·2019-08-28 18:08