準備
在此之前,我們先在我們的數據庫中插入10萬條數據。數據的格式是這樣的:
{
"name":"your name",
"age":22,
"gender":"male",
"grade":2
}
explain
explain方法是用來查看db.collecion.find()
的一些查詢信息的。例如:
db.collectionName.find().explain()
explain方法有個可選的參數verbose,是個字符串,他表示的是verbose的模式。一共分為3種模式:
queryPlanner:默認參數,詳細說明查詢優化器選擇的計劃并列出被拒絕的計劃。例如:
db.students.find({grade:1}).explain()

executionStats:MongoDB運行查詢優化器選擇獲勝的計劃,執行計劃,完成并返回成功,統計描述的勝利計劃的執行。例如:
db.students.find({grade:1}).explain("executionStats")

allPlansExecution:MongoDB返回描述獲獎計劃的執行以及對其他候選人統計計劃選擇方案時捕獲的統計。
我們的目的是要記錄執行find方法的耗時時間,所以用executionStats模式就可以了。
返回的結果也是只關注executionStats就可以了,如下圖:

- nReturned:表示該查詢條件下返回的文檔數量。
- executionTimeMills:表示執行時間,單位毫秒
- totalDocsExamined:表示該集合總共文檔數。
其他的屬性在這里就不多說了,記錄耗時我們只取executionTimeMills.
Profiling
上面提到的方法好像是只適用find方法,對于一些聚合查詢之類的查詢方法就無法統計耗時時間了。這里再介紹一個profiling方法記錄查詢耗時時間。
開啟 Profiling 功能
有兩種方式可以控制 Profiling 的開關和級別,第一種是直接在啟動參數里直接進行設置。
- 啟動MongoDB時加上–profile=級別 即可。
- 也可以在客戶端調用
db.setProfilingLevel
(級別)命令來實時配置。可以通過db.getProfilingLevel()
命令來獲取當前的Profile級別。
例如:
db.setProfilingLevel(2)
db.getProfilingLevel()

Profiling一共分為3個級別:
- 0 - 不開啟。
- 1 - 記錄慢命令 (默認為>100ms)
- 3 - 記錄所有命令
Profile 記錄在級別1時會記錄慢命令,那么這個慢的定義是什么?上面我們說到其默認為100ms,當然有默認就有設置,其設置方法和級別一樣有兩種,一種是通過添 加–slowms啟動參數配置。第二種是調用db.setProfilingLevel
時加上第二個參數:
db.setProfilingLevel( level , slowms)
db.setProfilingLevel( 1 , 10 );
查詢 Profiling 記錄
開啟profiling功能后,系統會把相關命令詳細信息記錄到當前數據庫的system.profile
集合里。查詢方法也是跟普通的集合查詢一樣。

其中,mills就是命令耗時記錄。
由于我們設置的級別是2,所以所有命令都有記錄,現在我們把他改為級別1,且只記錄耗時20毫秒以上的記錄:
db.setProfilingLevel( 1 , 20)

然后我們再執行一下聚合查詢,查看下耗時時間:
db.students.aggregate( {$group:{_id:"$grade",avgAge:{$avg:"$age"}}} )

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

可以看出,我們的這聚合查詢耗時70毫秒。
profile 部分字段解釋
- op:操作類型
- ns:被查的集合
- commond:命令的內容
- docsExamined:掃描文檔數
- nreturned:返回記錄數
- millis:耗時時間,單位毫秒
- ts:命令執行時間
- responseLength:返回內容長度
下面介紹幾個常用的查詢命令:
列出執行時間長于某一限度(例如:20ms)的 Profile 記錄.
db.system.profile.find({millis:{$gt:50}})

查看最新的 3條Profile 記錄:
db.system.profile.find().sort({$natural:-1}).limit(3)

查看關于某個collection的相關慢查詢操作:
db.system.profile.find({ns:'mydb.students'})
MongoDB 查詢優化
docsExamined(掃描的記錄數)遠大于nreturned(返回結果的記錄數)的話,那么我們就要考慮通過加索引來優化記錄定位了。
responseLength 如果過大,那么說明我們返回的結果集太大了,這時請查看find函數的第二個參數是否只寫上了你需要的屬性名。(類似 于MySQL中不要總是select)
對于創建索引的建議是:如果很少讀,那么盡量不要添加索引,因為索引越多,寫操作會越慢。如果讀量很大,那么創建索引還是比較劃算的。
Profiler 的效率
Profiling 功能肯定是會影響效率的,但是不太嚴重,原因是他使用的是system.profile 來記錄,而system.profile
是一個capped collection 這種collection 在操作上有一些限制和特點,但是效率更高。
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
您可能感興趣的文章:- 關于Mongodb 認證鑒權你需要知道的一些事
- linux系統下MongoDB單節點安裝教程
- vue+socket.io+express+mongodb 實現簡易多房間在線群聊示例
- node.js操作MongoDB的實例詳解
- windows7下使用MongoDB實現倉儲設計
- java操作mongoDB查詢的實例詳解
- MongoDB 3.4 安裝以 Windows 服務方式運行的詳細步驟
- 詳解MongoDB數據庫基礎操作及實例
- MongoDB TTL索引的實例詳解