MongoDB 查询优化分析
本文内容纲要：
摘要：
在MySQL中，慢查询日志是经常作为我们优化查询的依据，那在MongoDB中是否有类似的功能呢？答案是肯定的，那就是开启Profiling功能。该工具在运行的实例上收集有关MongoDB的写操作，游标，数据库命令等，可以在数据库级别开启该工具，也可以在实例级别开启。该工具会把收集到的所有都写入到system.profile集合中，该集合是一个cappedcollection。更多的信息见：http://docs.mongodb.org/manual/tutorial/manage-the-database-profiler/和http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=207007436&idx=1&sn=a63601d81c8d112228c96ad9fffb031c&scene=21#wechat_redirect
使用说明：
1：Profiling级别说明
0：关闭，不收集任何数据。
1：收集慢查询数据，默认是100毫秒。
2：收集所有数据
2：开启Profiling和设置
1：通过mongoshell:
#查看状态：级别和时间
drug:PRIMARY>db.getProfilingStatus()
{"was":1,"slowms":100}
#查看级别
drug:PRIMARY>db.getProfilingLevel()
1
#设置级别
drug:PRIMARY>db.setProfilingLevel(2)
{"was":1,"slowms":100,"ok":1}
#设置级别和时间
drug:PRIMARY>db.setProfilingLevel(1,200)
{"was":2,"slowms":100,"ok":1}
以上要操作要是在test集合下面的话，只对该集合里的操作有效，要是需要对整个实例有效，则需要在所有的集合下设置或则在开启的时候开启参数：
2：不通过mongoshell:
mongod--profile=1--slowms=15
或则在配置文件里添加2行：
profile=1
slowms=300
3：关闭Profiling
#关闭
drug:PRIMARY>db.setProfilingLevel(0)
{"was":1,"slowms":200,"ok":1}
4：修改“慢查询日志”的大小
#关闭Profiling
drug:PRIMARY>db.setProfilingLevel(0)
{"was":0,"slowms":200,"ok":1}
#删除system.profile集合
drug:PRIMARY>db.system.profile.drop()
true
#创建一个新的system.profile集合
drug:PRIMARY>db.createCollection("system.profile",{capped:true,size:4000000})
{"ok":1}
#重新开启Profiling
drug:PRIMARY>db.setProfilingLevel(1)
{"was":0,"slowms":200,"ok":1}
注意：要改变Secondary的system.profile的大小，你必须停止Secondary，运行它作为一个独立的，然后再执行上述步骤。完成后，重新启动加入副本集。
慢查询(system.profile)说明：
通过下面的例子说明，更多信息见：http://docs.mongodb.org/manual/reference/database-profiler/
1：参数含义
drug:PRIMARY>db.system.profile.find().pretty()
{
"op":"query",#操作类型，有insert、query、update、remove、getmore、command
"ns":"mc.user",#操作的集合
"query":{#查询语句
"mp_id":5,
"is_fans":1,
"latestTime":{
"$ne":0
},
"latestMsgId":{
"$gt":0
},
"$where":"newDate(this.latestNormalTime)>newDate(this.replyTime)"
},
"cursorid":NumberLong("1475423943124458998"),
"ntoreturn":0,#返回的记录数。例如，profile命令将返回一个文档（一个结果文件），因此ntoreturn值将为1。limit(5)命令将返回五个文件，因此ntoreturn值是5。如果ntoreturn值为0，则该命令没有指定一些文件返回，因为会是这样一个简单的find()命令没有指定的限制。
"ntoskip":0,#skip()方法指定的跳跃数
"nscanned":304,#扫描数量
"keyUpdates":0,#索引更新的数量，改变一个索引键带有一个小的性能开销，因为数据库必须删除旧的key，并插入一个新的key到B-树索引
"numYield":0,#该查询为其他查询让出锁的次数
"lockStats":{#锁信息，R：全局读锁；W：全局写锁；r：特定数据库的读锁；w：特定数据库的写锁
"timeLockedMicros":{#锁
"r":NumberLong(19467),
"w":NumberLong(0)
},
"timeAcquiringMicros":{#锁等待
"r":NumberLong(7),
"w":NumberLong(9)
}
},
"nreturned":101,#返回的数量
"responseLength":74659,#响应字节长度
"millis":19,#消耗的时间（毫秒）
"ts":ISODate("2014-02-25T02:13:54.899Z"),#语句执行的时间
"client":"127.0.0.1",#链接ip或则主机
"allUsers":[],
"user":""#用户
}
除上面外还有：
scanAndOrder：
scanAndOrder是一个布尔值，是True当一个查询不能使用的文件的顺序在索引中的排序返回结果：MongoDB中必须将其接收到的文件从一个游标后的文件进行排序。
如果scanAndOrder是False，MongoDB的可使用这些文件的顺序索引返回排序的结果。即：True：文档进行排序，False：使用索引。
moved
更新操作在磁盘上移动一个或多个文件到新的位置。表明本次update是否移动了硬盘上的数据，如果新记录比原记录短，通常不会移动当前记录，如果新记录比原记录长，那么可能会移动记录到其它位置，这时候会导致相关索引的更新.磁盘操作更多，加上索引
更新，会使得这样的操作比较慢.
nmoved：
文件在磁盘上操作。
nupdated：
更新文档的数目
getmore是一个getmore操作，getmore通常发生在结果集比较大的查询时，第一个query返回了部分结果，后续的结果是通过getmore来获取的。
如果nscanned(扫描的记录数)远大于nreturned(返回结果的记录数)的话，要考虑通过加索引来优化记录定位了。responseLength如果过大，说明返回的结果集太大了，这时要看是否只需要必要的字段。
2：日常使用的查询
#返回最近的10条记录
db.system.profile.find().limit(10).sort({ts:-1}).pretty()
#返回所有的操作，除command类型的
db.system.profile.find({op:{$ne:'command'}}).pretty()
#返回特定集合
db.system.profile.find({ns:'mydb.test'}).pretty()
#返回大于5毫秒慢的操作
db.system.profile.find({millis:{$gt:5}}).pretty()
#从一个特定的时间范围内返回信息
db.system.profile.find(
{
ts:{
$gt:newISODate("2012-12-09T03:00:00Z"),
$lt:newISODate("2012-12-09T03:40:00Z")
}
}
).pretty()
#特定时间，限制用户，按照消耗时间排序
db.system.profile.find(
{
ts:{
$gt:newISODate("2011-07-12T03:00:00Z"),
$lt:newISODate("2011-07-12T03:40:00Z")
}
},
{user:0}
).sort({millis:-1})
总结：
Profiling功能肯定是会影响效率的，但是不太严重，原因是他使用的是system.profile来记录，而system.profile是一个cappedcollection这种collection在操作上有一些限制和特点，但是效率更高，所以在使用的时候可以打开该功能，不需要一直打开。
本文内容总结：
原文链接：https://www.cnblogs.com/zhoujinyi/p/3566773.html