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 官網連結 見下文評論