mongodb慢查询分析

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 官网链接 见下文评论