這篇主要講解的是 MongoDB explain
指令的 executionStats
項目。
使用此模式進行 explain,會根據你輸入的語法,在 query optimizer 找出最佳的查詢計畫,並且 實際執行你的語法,無論是查詢或者新增刪除修改。但是請不用擔心,這樣做並不會真的去改變任何資料庫內容,只是協助、更貼近真實情況下,你的語法執行結果如何。
查詢語法在 explain 參數中帶入 executionStats
,即可。
db.collection.find().explain("executionStats")
馬上進入重頭戲,實際執行的部分。我們沿用了上一篇文章的範例,一樣是查詢 name
欄位,參數則指令了executionStats。
db.collection.find("name":"Devil").explain("executionStats")
queryPlanner
、serverInfo
"executionStats" : {
"executionSuccess" : true, // 執行結果
"nReturned" : 1, // 回傳了幾個文件
"executionTimeMillis" : 0, // 執行時間
"totalKeysExamined" : 1, // 總共掃瞄了幾把 key (代表有走在 index 上)
"totalDocsExamined" : 1, // 總共檢查了幾個檔案
"executionStages" : { // 執行階段
"stage" : "FETCH", // 執行此語法使用的方式,使用 index 查詢檔案
"nReturned" : 1, // 回傳了幾個檔案
"executionTimeMillisEstimate" : 0,
"works" : 2,
"advanced" : 1,
"needTime" : 0,
"needYield" : 0,
"saveState" : 0,
"restoreState" : 0,
"isEOF" : 1,
"invalidates" : 0,
"docsExamined" : 1, // 掃描了幾個檔案
"alreadyHasObj" : 0,
"inputStage" : {
"stage" : "IXSCAN", // 在執行階段,先使用了什麼方式查找,這邊是使用 index
"nReturned" : 1,
"executionTimeMillisEstimate" : 0,
"works" : 2,
"advanced" : 1,
"needTime" : 0,
"needYield" : 0,
"saveState" : 0,
"restoreState" : 0,
"isEOF" : 1,
"invalidates" : 0,
"keyPattern" : {
"name" : 1.0
},
"indexName" : "name_1", // 使用的 index 名稱
"isMultiKey" : false, // 是否為 multi key,如果是在 array 上建立 index,會是 true
"multiKeyPaths" : {
"name" : []
},
"isUnique" : false, // index 屬性,這三個可以回頭查看我之前 index 文章
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward", // 排序方向,順向。如果有 sort -1,就會是 backward
"indexBounds" : {
"name" : [
"[\"Devil\", \"Devil\"]"
]
},
"keysExamined" : 1,
"seeks" : 1,
"dupsTested" : 0,
"dupsDropped" : 0,
"seenInvalidated" : 0
}
}
}
比較簡單的部分就直接在範例後面註解了。
首先我們看一下這個結構
"executionStats":{
"executionStages":{
"inputStage":{
"stage" : "IXSCAN"
...
}
}
}
winningPlan 是一個樹狀的結構,實際上會根據你的查詢語法而有一個或多個 inputStage
,所以你可以看到 inputStages
會變成是複數型態。
例如我們今天分別提 age
, name
兩個欄位分別新增各一把 index,再使用 or
語法來查詢
db.employee.createIndex( { name: 1 } )
db.employee.createIndex( { age: 1 } )
db.employee.find({$or: [{"age":35} ,{"name":"Devil"}] }).explain("executionStats")
就會出現兩個 inputStage,如下:
"winningPlan" : {
"stage" : "SUBPLAN",
"inputStage" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "OR",
"inputStages" : [
{
"stage" : "IXSCAN",
"keyPattern" : {
"name" : 1.0
},
"indexName" : "name_1",
},
{
"stage" : "IXSCAN",
"keyPattern" : {
"age" : 1.0
},
"indexName" : "age_1",
}
]
}
}
}
executionStats 格式也是一樣的,但因為內容更多,所以這邊是先貼 winningPlan 結果。
那如果今天我只有一把 key,但還是用 or 來查詢兩個欄位,那會變成什麼結果呢?
答案是 1 個 inputStage,因為已經是 COLLSCAN 囉~
官網特別提到的項目,關於 $or
與 $in
運算子,官方直接告訴你要使用$in
。
假設你要查詢 name 欄位是 "Ada" 或 "Bob",不要使用
{$or: [{"name":"Ada"}, {"name":"Bob"}]}
{"name":{$in:["Ada", "Bob"]}}
個人補充:依我的經驗,因為看到官方提到這個案例,於是在猜想否定類型的運算子是不是也有相同效能問題,後來經過測試,確實是效能比較差,例如 $nin
這種。(當時是 3 版左右吧,不確定現在怎麼樣 5.0.1 了...)
works : 2
這個 works
就連官方文件都著墨得少。 works 可分為多個工作單元 work unit
,像是查詢 single field index key,或是依照 key 讀取回一個文件,或是針對取回文件進行 project
都算是一個工作單元,基本上就是最小工作單位的意思。假設一個好的查詢,通常會是 nReturned 的數量 +1,為什麼呢? nReturned 就是你查詢返回的文件數量,+1 則代表是查詢 index 這件工作,因此整體就是 works = nReturned+1。
isEOF : 1,
執行階段是否已經讀取到結尾的地方。
0
代表尚未1
代表是0
呢?通常是查詢語法中帶有 limt
的語法,使得該次查詢並不會查到結尾。其實還是有很多欄位是我不太理解的,也許之後有翻到文件會再記錄下來。至於沒寫到的,就應該是連相關文獻都找不到了XD
{field_a:1, field_b:'b01'},
{field_a:1, field_b:'b012'},
{field_a:2, field_b:'b02'},
{field_a:2, field_b:'b022'},
{field_a:2, field_b:'b023'},
{field_a:3, field_b:'b03'}
我們替 field_a
建立索引,假設查詢是 {field_a:2}
,那沒什麼問題。
那如果我們查詢的是 {field_a:2, field_b:'b023'}
,那麼 MongoDB 就必須要找遍 3 個文件才能找到正確的文件。
從上面的例子能理解獨特性的重要,至於要怎麼解這個問題,使用 compound index
就能處理。
status = 'ERROR'
的狀態資料是我們關注的,時常需要去看,這個情境就很適合 partial index本系列文章會同步發表於我個人的部落格 Pie Note