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})