本文為轉(zhuǎn)載，原文：MongoDB查詢(xún)耗時(shí)記錄方法

準(zhǔn)備

在此之前，我們先在我們的數(shù)據(jù)庫(kù)中插入10萬(wàn)條數(shù)據(jù)。數(shù)據(jù)的格式是這樣的：

{
  "name":"your name",
  "age":22,
  "gender":"male",
  "grade":2
}

explain

explain方法是用來(lái)查看db.collecion.find()的一些查詢(xún)信息的。例如：

db.collectionName.find().explain()

explain方法有個(gè)可選的參數(shù)verbose，是個(gè)字符串，他表示的是verbose的模式。一共分為3種模式：

• queryPlanner：默認(rèn)參數(shù)，詳細(xì)說(shuō)明查詢(xún)優(yōu)化器選擇的計(jì)劃并列出被拒絕的計(jì)劃。例如：

db.students.find({grade:1}).explain()

• executionStats：MongoDB運(yùn)行查詢(xú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：表示該查詢(xún)條件下返回的文檔數(shù)量。
• executionTimeMills：表示執(zhí)行時(shí)間，單位毫秒
• totalDocsExamined：表示該集合總共文檔數(shù)。

其他的屬性在這里就不多說(shuō)了，記錄耗時(shí)我們只取executionTimeMills.

Profiling

上面提到的方法好像是只適用find方法，對(duì)于一些聚合查詢(xún)之類(lèi)的查詢(xún)方法就無(wú)法統(tǒng)計(jì)耗時(shí)時(shí)間了。這里再介紹一個(gè)profiling方法記錄查詢(xún)耗時(shí)時(shí)間。

開(kāi)啟 Profiling 功能

有兩種方式可以控制 Profiling 的開(kāi)關(guān)和級(jí)別，第一種是直接在啟動(dòng)參數(shù)里直接進(jìn)行設(shè)置。
　　啟動(dòng)MongoDB時(shí)加上–profile=級(jí)別 即可。
　　也可以在客戶(hù)端調(diào)用db.setProfilingLevel(級(jí)別)命令來(lái)實(shí)時(shí)配置?？梢酝ㄟ^(guò)db.getProfilingLevel()命令來(lái)獲取當(dāng)前的Profile級(jí)別。例如：

db.setProfilingLevel(2)
db.getProfilingLevel()

db.setProfilingLevel( level , slowms)
db.setProfilingLevel( 1 , 10 );

查詢(xún) Profiling 記錄

開(kāi)啟profiling功能后，系統(tǒng)會(huì)把相關(guān)命令詳細(xì)信息記錄到當(dāng)前數(shù)據(jù)庫(kù)的system.profile集合里。查詢(xún)方法也是跟普通的集合查詢(xún)一樣。

db.system.profile.find()

 db.setProfilingLevel( 1 , 20)

然后我們?cè)賵?zhí)行一下聚合查詢(xún)，查看下耗時(shí)時(shí)間：

db.students.aggregate( {$group:{_id:"$grade",avgAge:{$avg:"$age"}}} )

db.system.profile.find().pretty()

可以看出，我們的這聚合查詢(xún)耗時(shí)70毫秒。

profile 部分字段解釋

op：操作類(lèi)型
ns：被查的集合
commond：命令的內(nèi)容
docsExamined：掃描文檔數(shù)
nreturned：返回記錄數(shù)
millis：耗時(shí)時(shí)間，單位毫秒
ts：命令執(zhí)行時(shí)間
responseLength：返回內(nèi)容長(zhǎng)度

下面介紹幾個(gè)常用的查詢(xún)命令：

1. 列出執(zhí)行時(shí)間長(zhǎng)于某一限度(例如：20ms)的 Profile 記錄.

db.system.profile.find({millis:{$gt:50}})

2. 查看最新的 3條Profile 記錄：

db.system.profile.find().sort({$natural:-1}).limit(3)

3. 查看關(guān)于某個(gè)collection的相關(guān)慢查詢(xún)操作：

db.system.profile.find({ns:'mydb.students'})

MongoDB 查詢(xún)優(yōu)化

docsExamined(掃描的記錄數(shù))遠(yuǎn)大于nreturned(返回結(jié)果的記錄數(shù))的話(huà)，那么我們就要考慮通過(guò)加索引來(lái)優(yōu)化記錄定位了。
　　responseLength 如果過(guò)大，那么說(shuō)明我們返回的結(jié)果集太大了，這時(shí)請(qǐng)查看find函數(shù)的第二個(gè)參數(shù)是否只寫(xiě)上了你需要的屬性名。(類(lèi)似 于MySQL中不要總是select)
　　對(duì)于創(chuàng)建索引的建議是：如果很少讀，那么盡量不要添加索引，因?yàn)樗饕蕉?，?xiě)操作會(huì)越慢。如果讀量很大，那么創(chuàng)建索引還是比較劃算的。

Profiler 的效率

Profiling 功能肯定是會(huì)影響效率的，但是不太嚴(yán)重，原因是他使用的是system.profile 來(lái)記錄，而system.profile 是一個(gè)capped collection 這種collection 在操作上有一些限制和特點(diǎn)，但是效率更高。

完