在MongoDB中，如果发生了慢查询，我们如何得到这些慢查询的语句，并优化呢？今天来看这块儿的一些心得。
01 如何收集慢查询？在MongoDB中，通常可以开启profile来收集慢日志，查看当前profile状态的语句如下：
这里我们可以看到2个关键参数，分别是was和slowms，其中：
was=0,代表不记录任何的语句；
was=1,代表记录执行时间超过slowms的语句
was=2,代表记录所有的语句
slowms代表语句的阈值，单位是ms
上图中的结果代表我们的实例会收集所有的查询语句。profile收集的查询语句结果存放在admin数据库中的system.profile集合中，可以通过下面的方法进行访问：
02 system.profile慢查询集合分析admin数据库中的system.profile是一个固定集合，保存着超过设置的慢查询的结果。我们来看里面的一条慢查询。
利用下面的方法，来拿到一条数据，并对其中的关键字段进行注释说明：
03 慢查询分析利器---explain通常情况下，我们可以使用MongoDB的explain语法来分析一个语句的查询性能，包含是否用到索引、扫描行数等信息，explain语法的基本用法:
其中，explain可以放在查询语句的后面或者前面，当然find语法也可以是update、remove、insert
explain语法的输出分为3种不同的详细程度，分别如下：
三种清晰度模式，清晰度越高，则输出的信息越全，默认情况下是queryPlanner：
1、queryPlanner模式(默认) db.products.explain().count( { quantity: { $gt: 50 } } )
2、executionStats模式 db.products.explain("executionStats").count( { quantity: { $gt: 50 } } )
3、allPlansExecution模式 db.products.explain("allPlansExecution").count( { quantity: { $gt: 50 } } )
其中，allPlansExecution模式输出的信息最多。
下面是一个explain语法的输出内容，查询的SQL如下：
输出的结果如下：
首先解释下stage的几个阶段：
COLLSCAN---全表扫描 IXSCAN---索引扫描 FETCH---根据索引去检索文档 SHARD_MERGE---合并分片结果 IDHACK---针对id进行查询 LIMIT---执行limit了解了这些stage的阶段之后，我们可以看到，一个查询的过程是一层一层解析的，所以可以看到，stage这个字段有嵌套的情况。winningPlan中的执行计划也是按照一层一层的顺序去执行：
1、先执行最内层的索引扫描(IXSCAN)；
2、再执行外面的FETCH，根据索引去拿文档
3、执行最后一步的limit，取指定数目个结果返回给客户端
以上就是MongoDB profile分析慢查询的示例的详细内容，更多关于MongoDB profile分析慢查询的资料请关注七叶笔记其它相关文章！
