準(zhǔn)備 在此之前,我們先在我們的數(shù)據(jù)庫中插入10萬條數(shù)據(jù)。數(shù)據(jù)的格式是這樣的: { "name":"your name", "age":22, "gender":"male", "grade":2 } explain explain方法是用來查看db.collecion.find()的一些查詢信息的。例如: db.collectionName.find().explain() explain方法有個(gè)可選的參數(shù)verbose,是個(gè)字符串,他表示的是verbose的模式。一共分為3種模式: queryPlanner:默認(rèn)參數(shù),詳細(xì)說明查詢優(yōu)化器選擇的計(jì)劃并列出被拒絕的計(jì)劃。例如: db.students.find({grade:1}).explain() executionStats:MongoDB運(yùn)行查詢優(yōu)化器選擇獲勝的計(jì)劃,執(zhí)行計(jì)劃,完成并返回成功,統(tǒng)計(jì)描述的勝利計(jì)劃的執(zhí)行。例如: db.students.find({grade:1}).explain("executionStats") allPlansExecution:MongoDB返回描述獲獎(jiǎng)計(jì)劃的執(zhí)行以及對(duì)其他候選人統(tǒng)計(jì)計(jì)劃選擇方案時(shí)捕獲的統(tǒng)計(jì)。 我們的目的是要記錄執(zhí)行find方法的耗時(shí)時(shí)間,所以用executionStats模式就可以了。 返回的結(jié)果也是只關(guān)注executionStats就可以了,如下圖: nReturned:表示該查詢條件下返回的文檔數(shù)量。 executionTimeMills:表示執(zhí)行時(shí)間,單位毫秒 totalDocsExamined:表示該集合總共文檔數(shù)。 其他的屬性在這里就不多說了,記錄耗時(shí)我們只取executionTimeMills. Profiling 上面提到的方法好像是只適用find方法,對(duì)于一些聚合查詢之類的查詢方法就無法統(tǒng)計(jì)耗時(shí)時(shí)間了。這里再介紹一個(gè)profiling方法記錄查詢耗時(shí)時(shí)間。 開啟 Profiling 功能 有兩種方式可以控制 Profiling 的開關(guān)和級(jí)別,第一種是直接在啟動(dòng)參數(shù)里直接進(jìn)行設(shè)置。 啟動(dòng)MongoDB時(shí)加上-Cprofile=級(jí)別 即可。 也可以在客戶端調(diào)用db.setProfilingLevel(級(jí)別)命令來實(shí)時(shí)配置?梢酝ㄟ^db.getProfilingLevel()命令來獲取當(dāng)前的Profile級(jí)別。 例如: db.setProfilingLevel(2) db.getProfilingLevel() Profiling一共分為3個(gè)級(jí)別: 0 - 不開啟。 1 - 記錄慢命令 (默認(rèn)為>100ms) 3 - 記錄所有命令 Profile 記錄在級(jí)別1時(shí)會(huì)記錄慢命令,那么這個(gè)慢的定義是什么?上面我們說到其默認(rèn)為100ms,當(dāng)然有默認(rèn)就有設(shè)置,其設(shè)置方法和級(jí)別一樣有兩種,一種是通過添 加-Cslowms啟動(dòng)參數(shù)配置。第二種是調(diào)用db.setProfilingLevel時(shí)加上第二個(gè)參數(shù): db.setProfilingLevel( level , slowms) db.setProfilingLevel( 1 , 10 ); 查詢 Profiling 記錄 開啟profiling功能后,系統(tǒng)會(huì)把相關(guān)命令詳細(xì)信息記錄到當(dāng)前數(shù)據(jù)庫的system.profile集合里。查詢方法也是跟普通的集合查詢一樣。 db.system.profile.find() 其中,mills就是命令耗時(shí)記錄。 由于我們?cè)O(shè)置的級(jí)別是2,所以所有命令都有記錄,現(xiàn)在我們把他改為級(jí)別1,且只記錄耗時(shí)20毫秒以上的記錄: db.setProfilingLevel( 1 , 20) 然后我們?cè)賵?zhí)行一下聚合查詢,查看下耗時(shí)時(shí)間: db.students.aggregate( {$group:{_id:"$grade",avgAge:{$avg:"$age"}}} ) db.system.profile.find().pretty() 可以看出,我們的這聚合查詢耗時(shí)70毫秒。 profile 部分字段解釋 op:操作類型 ns:被查的集合 commond:命令的內(nèi)容 docsExamined:掃描文檔數(shù) nreturned:返回記錄數(shù) millis:耗時(shí)時(shí)間,單位毫秒 ts:命令執(zhí)行時(shí)間 responseLength:返回內(nèi)容長度 下面介紹幾個(gè)常用的查詢命令: 列出執(zhí)行時(shí)間長于某一限度(例如:20ms)的 Profile 記錄. db.system.profile.find({millis:{$gt:50}}) 查看最新的 3條Profile 記錄: db.system.profile.find().sort({$natural:-1}).limit(3) 查看關(guān)于某個(gè)collection的相關(guān)慢查詢操作: db.system.profile.find({ns:'mydb.students'}) MongoDB 查詢優(yōu)化 docsExamined(掃描的記錄數(shù))遠(yuǎn)大于nreturned(返回結(jié)果的記錄數(shù))的話,那么我們就要考慮通過加索引來優(yōu)化記錄定位了。 responseLength 如果過大,那么說明我們返回的結(jié)果集太大了,這時(shí)請(qǐng)查看find函數(shù)的第二個(gè)參數(shù)是否只寫上了你需要的屬性名。(類似 于MySQL中不要總是select) 對(duì)于創(chuàng)建索引的建議是:如果很少讀,那么盡量不要添加索引,因?yàn)樗饕蕉,寫操作?huì)越慢。如果讀量很大,那么創(chuàng)建索引還是比較劃算的。 Profiler 的效率 Profiling 功能肯定是會(huì)影響效率的,但是不太嚴(yán)重,原因是他使用的是system.profile 來記錄,而system.profile 是一個(gè)capped collection 這種collection 在操作上有一些限制和特點(diǎn),但是效率更高。 |
免責(zé)聲明:本站部分文章和圖片均來自用戶投稿和網(wǎng)絡(luò)收集,旨在傳播知識(shí),文章和圖片版權(quán)歸原作者及原出處所有,僅供學(xué)習(xí)與參考,請(qǐng)勿用于商業(yè)用途,如果損害了您的權(quán)利,請(qǐng)聯(lián)系我們及時(shí)修正或刪除。謝謝!
始終以前瞻性的眼光聚焦站長、創(chuàng)業(yè)、互聯(lián)網(wǎng)等領(lǐng)域,為您提供最新最全的互聯(lián)網(wǎng)資訊,幫助站長轉(zhuǎn)型升級(jí),為互聯(lián)網(wǎng)創(chuàng)業(yè)者提供更加優(yōu)質(zhì)的創(chuàng)業(yè)信息和品牌營銷服務(wù),與站長一起進(jìn)步!讓互聯(lián)網(wǎng)創(chuàng)業(yè)者不再孤獨(dú)!
掃一掃,關(guān)注站長網(wǎng)微信