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 官網鏈接 見下文評論