深入讲解MongoDB的慢日志查询（profile）

前言

说到mongodb的慢日志分析，就不得不提到profile分析器，profile分析器将记录的慢日志写到system.profile集合下，这个集合是一个固定集合。我们可以通过对这个集合的查询，来了解当前的慢日志，进而对数据库进行优化。

整体环境

mongodb 3.2.5

实战

part1:输出示范

在查询system.profile的时候，我们能够观察到所有的操作，包括remove,update,find等等都会被记录到system.profile集合中，该集合中包含了诸多信息，如：

{
 "op" : "query",
 "ns" : "test.c",
 "query" : {
 "find" : "c",
 "filter" : {
  "a" : 1
 }
 },
 "keysexamined" : 2,
 "docsexamined" : 2,
 "cursorexhausted" : true,
 "keyupdates" : 0,
 "writeconflicts" : 0,
 "numyield" : 0,
 "locks" : {
 "global" : {
  "acquirecount" : {
  "r" : numberlong(2)
  }
 },
 "database" : {
  "acquirecount" : {
  "r" : numberlong(1)
  }
 },
 "collection" : {
  "acquirecount" : {
  "r" : numberlong(1)
  }
 }
 },
 "nreturned" : 2,
 "responselength" : 108,
 "millis" : 0,
 "execstats" : {
 "stage" : "fetch",
 "nreturned" : 2,
 "executiontimemillisestimate" : 0,
 "works" : 3,
 "advanced" : 2,
 "needtime" : 0,
 "needyield" : 0,
 "savestate" : 0,
 "restorestate" : 0,
 "iseof" : 1,
 "invalidates" : 0,
 "docsexamined" : 2,
 "alreadyhasobj" : 0,
 "inputstage" : {
  "stage" : "ixscan",
  "nreturned" : 2,
  "executiontimemillisestimate" : 0,
  "works" : 3,
  "advanced" : 2,
  "needtime" : 0,
  "needyield" : 0,
  "savestate" : 0,
  "restorestate" : 0,
  "iseof" : 1,
  "invalidates" : 0,
  "keypattern" : {
  "a" : 1
  },
  "indexname" : "a_1",
  "ismultikey" : false,
  "isunique" : false,
  "issparse" : false,
  "ispartial" : false,
  "indexversion" : 1,
  "direction" : "forward",
  "indexbounds" : {
  "a" : [
  "[1.0, 1.0]"
  ]
  },
  "keysexamined" : 2,
  "dupstested" : 0,
  "dupsdropped" : 0,
  "seeninvalidated" : 0
 }
 },
 "ts" : isodate("2015-09-03t15:26:14.948z"),
 "client" : "127.0.0.1",
 "allusers" : [ ],
 "user" : ""}

part2:输出解读

system.profile.op

这一项主要包含如下几类

1. insert
2. query
3. update
4. remove
5. getmore
6. command

代表了该慢日志的种类是什么，是查询、插入、更新、删除还是其他。

system.profile.ns

该项表明该慢日志是哪个库下的哪个集合所对应的慢日志。

system.profile.query

该项详细输出了慢日志的具体语句和行为

system.profile.keysexamined

该项表明为了找出最终结果mongodb搜索了多少个key

system.profile.docsexamined

该项表明为了找出最终结果mongodb搜索了多少个文档

system.profile.keyupdates

该项表名有多少个index key在该操作中被更改，更改索引键也会有少量的性能消耗，因为数据库不单单要删除旧key，还要插入新的key到b-tree索引中

system.profile.writeconflicts

写冲突发生的数量，例如update一个正在被别的update操作的文档

system.profile.numyield

为了让别的操作完成而屈服的次数，一般发生在需要访问的数据尚未被完全读取到内存中，mongodb会优先完成在内存中的操作

system.profile.locks

在操作中产生的锁，锁的种类有多种，如下：

global	represents global lock.
mmapv1journal	represents mmapv1 storage engine specific lock to synchronize journal writes; for non-mmapv1 storage engines, the mode formmapv1journal is empty.
database	represents database lock.
collection	represents collection lock.
metadata	represents metadata lock.
oplog	represents lock on the .

锁的模式也有多种，如下：

lock mode	description
r	represents shared (s) lock.
w	represents exclusive (x) lock.
r	represents intent shared (is) lock.
w	represents intent exclusive (ix) lock.

system.profile.locks.acquirecoun

在各种不用的种类下，请求锁的次数

system.profile.nreturned

该操作最终返回文档的数量

system.profile.responselength

结果返回的大小，单位为bytes，该值如果过大，则需考虑limit()等方式减少输出结果

system.profile.millis

该操作从开始到结束耗时多少，单位为毫秒

system.profile.execstats

包含了一些该操作的统计信息，只有query类型的才会显示

system.profile.execstats.stage

包含了该操作的详细信息，例如是否用到索引

system.profile.ts

该操作执行时的时间

system.profile.client

哪个客户端发起的该操作，并显示出该客户端的ip或hostname

system.profile.allusers

哪个认证用户执行的该操作

system.profile.user

是否认证用户执行该操作，如认证后使用其他用户操作，该项为空

总结

system.profile集合是定位慢sql的手段之一，了解每一个输出项的含义有助于我们更快的定位问题。由于笔者的水平有限，编写时间也很仓促，文中难免会出现一些错误或者不准确的地方，不妥之处恳请读者批评指正。

好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流，谢谢大家对的支持。