mongodb之使用explain和hint性能分析和優化

一：explain演示mongodb

1. 構建數據數據庫

爲了方便演示，我須要create ten data to inventory，並且仍是要在no index 的狀況下，好比下面這樣：app

 1 db.inventory.insertMany([
 2 { "_id" : 1, "item" : "f1", type: "food", quantity: 500 },
 3 { "_id" : 2, "item" : "f2", type: "food", quantity: 100 },
 4 { "_id" : 3, "item" : "p1", type: "paper", quantity: 200 },
 5 { "_id" : 4, "item" : "p2", type: "paper", quantity: 150 },
 6 { "_id" : 5, "item" : "f3", type: "food", quantity: 300 },
 7 { "_id" : 6, "item" : "t1", type: "toys", quantity: 500 },
 8 { "_id" : 7, "item" : "a1", type: "apparel", quantity: 250 },
 9 { "_id" : 8, "item" : "a2", type: "apparel", quantity: 400 },
10 { "_id" : 9, "item" : "t2", type: "toys", quantity: 50 },
11 { "_id" : 10, "item" : "f4", type: "food", quantity: 75 }]);

2. 無索引查詢性能

 b.inventory.find(
   { quantity: { $gte: 100, $lte: 200 } }
).explain("executionStats")

從上圖中，咱們看到了三個圈圈，這些都是咱們在find中很是重要的信息，具體信息解釋以下：優化

<1>COLLSCANui

這個是什麼意思呢？若是你仔細一看，應該知道就是CollectionScan，就是所謂的「集合掃描」，對不對，看到集合掃描是否是就能夠直接map到數據庫中的table scan/heap scan呢？？？是的，這個就是所謂的性能最爛最無奈的由來。spa

<2> nReturned3d

這個很簡單，就是所謂的numReturned，就是說最後返回的num個數，從圖中能夠看到，就是最終返回了三條。。。code

<3> docsExaminedblog

那這個是什麼意思呢？？就是documentsExamined，檢查了10個documents。。。而從返回上面的nReturned。。。

ok，那從上面三個信息中，咱們能夠得出，原來我examine 10 條數據，最終才返回3條，說明作了7條數據scan的無用功，那麼這個時候問題就來了，

如何減小examine的documents。。。

3. 使用single field 加速查找

知道來龍去脈以後，咱們就能夠進行鍼對性的創建索引，好比在quality字段之上，以下：

 db.inventory.createIndex({ quantity: 1})

db.inventory.find(
   { quantity: { $gte: 100, $lte: 200 } }
).explain("executionStats")

好了，這時候就有意思了，當咱們執行完createindex以後，再次explain，4個重要的parameters就漂下來了：

<1> IXSCAN

這個時候不再是所謂的COLLSCAN了，而是IndexScan，這就說明咱們已經命中索引了。

<2> nReturned,totalDocsExamined，totalKeysExamined

從圖中能夠看到三個參數都是3，這就說明咱們的mongodb查看了3個key，3個document，返回3個文檔，這個就是所謂的高性能所在，對吧。

二：hint演示

說到hint，我想你們也是知道的，很好玩的一個東西，就是用來force mongodb to excute special index，對吧，爲了方便演示，咱們作兩組複合索引，好比此次咱們在quality和type上構建一下：

building完成以後，咱們故意這一個這樣的查詢，針對quantity是一個範圍，而type是一個定值的狀況下，咱們force mongodb去使用quantity開頭的複合索引，從而強制mongodb give up 那個以{type:1,quantity:1}的複合索引，頗有意思哦，好比下圖：

從圖中，能夠看到，咱們檢查了6個keys，而從最終找到了2個文檔，如今咱們就知道了，2和6之間仍是有不足的地方等待咱們去優化了，對吧，下面咱們不hint來看一下mongodb的最優的plan是怎麼樣的。

除此以外，也能夠強迫查詢不適用索引，作表掃描：

db.users.find().hint({"$natural":1})