mongodb慢查詢---之白夜追兇業務背景

線上mongodb資料庫查詢資料超級慢，因為我們架構是分布式的架構，調用某個接口，接口查詢mongodb資料的時候，非常卡，導緻頁面加載很慢。那我們就追追兇手。。。。。

分别使用top、free -m 、iostat -x 1檢視伺服器的CPU、記憶體、硬碟IO使用情況，得出結論如下：

記憶體使用情況和平常無異；磁盤io使用率正常；偏偏cpu使用率很高。得出結論cpu資源耗盡，導緻産尋慢。

一個查詢掃描了多少文檔，可檢視 system.profile 裡的 docsExamined 的值，該值越大，請求CPU開銷越大。

關鍵字：COLLSCAN、 docsExamined

有的時候，請求即使查詢走了索引，執行也很慢，通常是因為合理建立不太合理（或者是比對的結果本身就很多，這樣即使走索引，請求開銷也不會優化很多）。

如下所示，假設某個集合的資料，x字段的取值很少（假設隻有1、2），而y字段的取值很豐富。

要服務 {x: 1: y: 2} 這樣的查詢

至于{y: 1} 與 {y: 1, x: 1} 的差別，可參考MongoDB索引原理 及 複合索引官方文檔 自行了解。

一個走索引的查詢，掃描了多少條索引，可檢視 system.profile 裡的 keysExamined 字段，該值越大，CPU 開銷越大。

關鍵字：IXSCAN、keysExamined

當查詢請求裡包含排序的時候，如果排序無法通過索引滿足，MongoDB 會在記憶體李結果進行排序，而排序這個動作本身是非常耗 CPU 資源的，優化的方法仍然是建立索引，對經常需要排序的字段，建立索引。

當你在 system.profile 集合 或者 日志檔案發現 SORT 關鍵字時，就可以考慮通過索引來優化排序。當請求包含排序階段時， system.profile 裡的 hasSortStage 字段會為 true。

關鍵字：SORT、hasSortStage

其他還有諸如建索引，aggregationv等操作也可能非常耗 CPU 資源，但本質上也是上述幾種場景；建索引需要全表掃描，而vaggeregation 也是周遊、查詢、更新、排序等動作的組合。

0：不記錄；1：記錄查詢超過500毫秒的記錄；2：記錄所有查詢記錄。

需要說的是，在設定級别和時間的時候，隻會在目前庫下生效，如果想記錄其它庫的慢查詢的話，需要進到對應的庫裡面進行設定。

ts：時間戳 

op: 操作類型

ns：執行操作的對象集合

millis：操作所花時間，毫秒 

client: 執行操作的用戶端

user: 執行操作的mongodb連接配接使用者

小編環境是讀寫分離的環境，是以要在從上檢視日志還需要執行一句話：

<code>SECONDARY&amp;gt; rs.slaveOk();</code>

本文轉自 xinsir999 51CTO部落格，原文連結：http://blog.51cto.com/xinsir/2051629，如需轉載請自行聯系原作者