DAY16 MongoDB Explain 與 Index 建議
MongoDB explain - executionStats
這篇主要講解的是 MongoDB explain
指令的 executionStats
項目。
使用此模式進行 explain,會根據你輸入的語法,在 query optimizer 找出最佳的查詢計畫,並且 實際執行你的語法,無論是查詢或者新增刪除修改。但是請不用擔心,這樣做並不會真的去改變任何資料庫內容,只是協助、更貼近真實情況下,你的語法執行結果如何。
查詢語法在 explain 參數中帶入 executionStats
,即可。
1 | db.collection.find().explain("executionStats") |
實際執行
馬上進入重頭戲,實際執行的部分。我們沿用了上一篇文章的範例,一樣是查詢 name
欄位,參數則指令了executionStats。
db.collection.find("name":"Devil").explain("executionStats")
- 我省略固定會出現的
queryPlanner
、serverInfo
- 如果這個範例後面沒有中文解釋,代表下面會解釋
1 | "executionStats" : { |
比較簡單的部分就直接在範例後面註解了。
首先我們看一下這個結構
1 | "executionStats":{ |
winningPlan 是一個樹狀的結構,實際上會根據你的查詢語法而有一個或多個 inputStage
,所以你可以看到 inputStages
會變成是複數型態。
例如我們今天分別提 age
, name
兩個欄位分別新增各一把 index,再使用 or
語法來查詢
1 | db.employee.createIndex( { name: 1 } ) |
就會出現兩個 inputStage,如下:
1 | "winningPlan" : { |
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
索引建議
- 建立的索引欄位必須與查詢語句有強關聯
通常我在確定需求後,會把所有使用者情境列出,並把查詢條件整理起來,這些大概就會是你所需要的索引了。 - 呈上,最好是 covered queries
- 即使是排序也需要索引
用來排序的欄位也需要在索引內,否則會資料庫排到崩潰,不對,應該是人會等到崩潰 - 建立的欄位最好是具有獨特性
1 | {field_a:1, field_b:'b01'}, |
我們替 field_a
建立索引,假設查詢是 {field_a:2}
,那沒什麼問題。
那如果我們查詢的是 {field_a:2, field_b:'b023'}
,那麼 MongoDB 就必須要找遍 3 個文件才能找到正確的文件。
從上面的例子能理解獨特性的重要,至於要怎麼解這個問題,使用 compound index
就能處理。
- 特定條件的查詢,替它們建立 partial index
使用情境上,我們時常會查詢某種狀態或條件的資料,例如status = 'ERROR'
的狀態資料是我們關注的,時常需要去看,這個情境就很適合 partial index - 多用 explain (對,這是建議,很基本也很重要)