1.用慢查询日志（system.profile）找到超过500ms的语句
mongos>db.setProfilingLevel(1,500)
2.然后再通过.explain()解析影响行数，分析为什么超过500ms【即看执行计划】 参见下文评论链接
3. 决定是否是缺失索引导致
#查看状态：级别和时间
PRIMARY> db.getProfilingStatus()
{ "was" : 1, "slowms" : 200 }
#查看级别
PRIMARY> db.getProfilingLevel()
1
#设置级别
PRIMARY> db.setProfilingLevel(2)
{ "was" : 1, "slowms" : 100, "ok" : 1 }
#设置级别和时间
PRIMARY> db.setProfilingLevel(1,200)
{ "was" : 2, "slowms" : 100, "ok" : 1 }
Profiling级别说明
参数：
0：关闭，不收集任何数据。
1：收集慢查询数据，默认是100毫秒。
2：收集所有数据
注意：
1 以上要操作要是在test集合下面的话，只对该集合里的操作有效，要是需要对整个实例有效，则需要在所有的集合下设置或则在开启的时候开启参数
2 每次设置之后返回给你的结果是修改之前的状态（包括级别、时间参数）
2：不通过mongo shell
在mongoDB启动的时候
mongod --profile=1 --slowms=200
或则在配置文件里添加2行：
profile = 1
slowms = 200
3：关闭Profiling
# 关闭
PRIMARY> db.setProfilingLevel(0)
{ "was" : 1, "slowms" : 200, "ok" : 1 }
4：修改“慢查询日志”的大小
#关闭Profiling
PRIMARY> db.setProfilingLevel(0)
{ "was" : 0, "slowms" : 200, "ok" : 1 }
#删除system.profile集合
PRIMARY> db.system.profile.drop()
慢查询(system.profile)分析
3.2: 分析
如果发现 millis 值比较大，那么就需要作优化。
1 如果nscanned数很大，或者接近记录总数（文档数），那么可能没有用到索引查询，而是全表扫描。
2 如果 nscanned 值高于 nreturned 的值，说明数据库为了找到目标文档扫描了很多文档。这时可以考虑创建索引来提高效率。
‘type’的返回参数说明：
COLLSCAN #全表扫描
IXSCAN #索引扫描
FETCH #根据索引去检索指定document
SHARD_MERGE #将各个分片返回数据进行merge
SORT #表明在内存中进行了排序（与老版本的scanAndOrder:true一致）
LIMIT #使用limit限制返回数
SKIP #使用skip进行跳过
IDHACK #针对_id进行查询
SHARDING_FILTER #通过mongos #对分片数据进行查询
COUNT #利用db.coll.explain().count()之类进行count运算
COUNTSCAN #count不使用Index进行count时的stage返回
COUNT_SCAN #count使用了Index进行count时的stage返回
SUBPLA #未使用到索引的$or查询的stage返回
TEXT #使用全文索引进行查询时候的stage返回
PROJECTION #限定返回字段时候stage的返回
对于普通查询，我们最希望看到的组合有这些：
Fetch+IDHACK
Fetch+ixscan
Limit+（Fetch+ixscan）
PROJECTION+ixscan
SHARDING_FILTER+ixscan
等
不希望看到包含如下的type：
COLLSCAN（全表扫），SORT（使用sort但是无index），不合理的SKIP，SUBPLA（未用到index的$or）
对于count查询，希望看到的有：
COUNT_SCAN
不希望看到的有:
COUNTSCAN
4 性能（explain） 参考mongodb 官网链接 见下文评论
