监控Mongo慢查询
1. 使用mongostat监控MongoDB全局情况
mongostat是mongdb自带的状态检测工具，在命令行下使用。它会间隔固定时间获取MongoDB的当前运行状态，并输出。
如果你发现数据库突然变慢或者有其他问题的话，你第一手的操作就考虑采用mongostat来查看mongo的状态。
mongostat --host localhost:27017 -uroot -p123456 --authenticationDatabase admin
参数说明：
host:指定IP地址和端口，也可以只写IP，然后使用--port参数指定端口号
-u： 如果开启了认证，则需要在其后填写用户名
-p: 密码
--authenticationDatabase：若开启了认证，则需要在此参数后填写认证库（注意是认证上述账号的数据库）
mongostat输出详解
insert/s : 官方解释是每秒插入数据库的对象数量，如果是slave，则数值前有*,则表示复制集操作
query/s : 每秒的查询操作次数
update/s : 每秒的更新操作次数
delete/s : 每秒的删除操作次数
getmore/s: 每秒查询cursor(游标)时的getmore操作数
command: 每秒执行的命令数，在主从系统中会显示两个值(例如 3|0),分表代表 本地|复制 命令
注： 一秒内执行的命令数比如批量插入，只认为是一条命令（所以意义应该不大）
dirty: 仅仅针对WiredTiger引擎，官网解释是脏数据字节的缓存百分比
used:仅仅针对WiredTiger引擎，官网解释是正在使用中的缓存百分比
flushes:
For WiredTiger引擎：指checkpoint的触发次数在一个轮询间隔期间
For MMAPv1 引擎：每秒执行fsync将数据写入硬盘的次数
注：一般都是0，间断性会是1， 通过计算两个1之间的间隔时间，可以大致了解多长时间flush一次。flush开销是很大的，
如果频繁的flush,可能就要找找原因了
vsize： 虚拟内存使用量，单位MB （这是 在mongostat 最后一次调用的总数据）
res: 物理内存使用量，单位MB （这是 在mongostat 最后一次调用的总数据）
注：这个和你用top看到的一样, vsize一般不会有大的变动， res会慢慢的上升，如果res经常突然下降，去查查是否有别的程序狂吃内存。
qr: 客户端等待从MongoDB实例读数据的队列长度
qw: 客户端等待从MongoDB实例写入数据的队列长度
ar: 执行读操作的活跃客户端数量
aw: 执行写操作的活客户端数量
注：如果这两个数值很大，那么就是DB被堵住了，DB的处理速度不及请求速度。看看是否有开销很大的慢查询。如果查询一切正常，确实是负载很大，就需要加机器了
netIn:MongoDB实例的网络进流量
netOut：MongoDB实例的网络出流量
注：此两项字段表名网络带宽压力，一般情况下，不会成为瓶颈
conn: 打开连接的总数，是qr,qw,ar,aw的总和
注：MongoDB为每一个连接创建一个线程，线程的创建与释放也会有开销，所以尽量要适当配置连接数的启动参数，
maxIncomingConnections，阿里工程师建议在5000以下，基本满足多数场景
set: 副本集的名称
repl: 节点的复制状态
M ---master
SEC ---secondary
REC ---recovering
UNK ---unknown
SLV ---slave
RTR ---mongs process("router')
ARB ---arbiter
2. 使用Profiling捕捉慢查询
类似于MySQL的slow log, mongodb可以监控所有慢的以及不慢的查询。这个工具就是Profiling，该工具在运行的实例上收集有关MongoDB的 写操作，游标，数据库命令等，可以在数据库级别开启该工具，也可以在实例级别开启。该工具会把收集到的所有都写入到system.profile集合中，该集合是一个capped collection。Profiling功能肯定是会影响效率的，但是不太严重，原因是他使用的是system.profile 来记录，而system.profile 是一个capped collection， 这种collection 在操作上有一些限制和特点，但是效率更高。
2.1 慢查询分析过程
1. 设置一个时间阀值,比如200ms
2. 在profiling中(system.profile)找到超过200ms的语句
3. 查看execStats,分析执行计划
4. 根据分析结果,决定是不是需要添加索引
2.2 Profiling基本操作
mongoshell(或者其他客户端比如mongochef等）
#查看状态：级别和时间
PRIMARY> db.getProfilingStatus()
{ "was" : 1, "slowms" : 200 }
#查看级别
PRIMARY> db.getProfilingLevel()
#级别说明:
0：关闭，不收集任何数据。
1：收集慢查询数据，默认是100毫秒。
2：收集所有数据
#设置级别
PRIMARY> db.setProfilingLevel(2)
{ "was" : 1, "slowms" : 100, "ok" : 1 } #这里返回的是上一次的设置
#设置级别和时间
PRIMARY> db.setProfilingLevel(1,200)
{ "was" : 2, "slowms" : 100, "ok" : 1 } #这里返回的是上一次的设置
#关闭Profiling
PRIMARY> db.setProfilingLevel(0)
{ "was" : 1, "slowms" : 200, "ok" : 1 } #这里返回的是上一次的设置
#清空system.profile或者修改大小
#关闭Profiling
PRIMARY> db.setProfilingLevel(0)
{ "was" : 0, "slowms" : 200, "ok" : 1 }
#删除system.profile集合
PRIMARY> db.system.profile.drop()
true
#创建一个新的system.profile集合 --- 4M
PRIMARY> db.createCollection( "system.profile", { capped: true, size:4000000 } )
{ "ok" : 1 }
#重新开启Profiling
PRIMARY> db.setProfilingLevel(1,200)
{ "was" : 0, "slowms" : 200, "ok" : 1 }
#如果是复制集环境,要修改副本的system.profile的大小,必须把副本先从复制集中剔除,然后执行上述步骤,最后加入复制集。
#也可以MongoDB启动时,开启Profiling
mongod --profile=1 --slowms=200
#或者在配置文件里添加
profile = 1
slowms = 200
3. 日常使用的Profiling查询脚本
#返回最近的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 : new ISODate("2015-10-18T03:00:00Z"),
$lt : new ISODate("2015-10-19T03:40:00Z")
}
}
).pretty()
#特定时间，限制用户，按照消耗时间排序
db.system.profile.find(
{
ts : {
$gt : newISODate("2015-10-12T03:00:00Z") ,
$lt : newISODate("2015-10-12T03:40:00Z")
}
},
{ user : 0 }
).sort( { millis : -1 } )
#查看最新的 Profile 记录：
db.system.profile.find().sort({$natural:-1}).limit(1)
# 显示5个最近的事件
show profile
4. 案例分析
4.1 获取慢查询
#下面的语句过滤几个大表,因为基本无法优化,需要开发改逻辑,所以做了排除，在输出方面只输出了个人认为重要的,方便分析迅速定位
db.system.profile.find({"ns":{"$not":{"$in":["F10data3.f10_4_4_1_gsgg_content", "F10data3.f10_5_1_1_gsyb_content"]}}}, {"ns":1,"op":1, "query":1,"keysExamined":1,"docsExamined":1,"numYield":1, "planSummary":1,"responseLength":1,"millis":1,"execStats":1}).limit(10).sort({ts:-1}).pretty()
#下面是一个超过200ms的查询语句
{
"op" : "query", #操作类型，有insert、query、update、remove、getmore、command
"ns" : "F10data3.f10_2_8_3_jgcc",
"query" : { #具体的查询语句 包括过滤条件，limit行数 排序字段
filter" : {
"jzrq" : {
"$gte" : ISODate("2017-03-31T16:00:00.000+0000"),
"$lte" : ISODate("2017-06-30T15:59:59.000+0000")
},
"jglxfldm" : 10.0
},
"ntoreturn" : 200.0,
"sort" : { #如果有排序 则显示排序的字段 这里是 RsId
"RsId" : 1.0
}
},
"keysExamined" : 0.0, #索引扫描数量 这里是全表扫描，没有用索引 所以是 0
"docsExamined" : 69608.0, #浏览的文档数 这里是全表扫描 所以是整个collection中的全部文档数
"numYield" : 546.0, #该操作为了使其他操作完成而放弃的次数。通常来说，当他们需要访问
还没有完全读入内存中的数据时，操作将放弃。这使得在MongoDB为了
放弃操作进行数据读取的同时，还有数据在内存中的其他操作可以完成。
"locks" : { #锁信息，R：全局读锁；W：全局写锁；r：特定数据库的读锁；w：特定数据库的写锁
"Global" : {
"acquireCount" : {
"r" : NumberLong(1094) #该操作获取一个全局级锁花费的时间。
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(547)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(547)
}
}
},
"nreturned" : 200.0, #返回的文档数量
"responseLength" : 57695.0, #返回字节长度，如果这个数字很大，考虑值返回所需字段
"millis" : 264.0, #消耗的时间（毫秒）
"planSummary" : "COLLSCAN, COLLSCAN", #执行概览 从这里看来 是全表扫描
"execStats" : { #详细的执行计划 这里先略过 后续可以用 explain来具体分析
},
"ts" : ISODate("2017-08-24T02:32:49.768+0000"), #命令执行的时间
"client" : "10.3.131.96", #访问的ip或者主机
"allUsers" : [
],
"user" : ""
}
4.2 分析慢查询
1. 如果发现 millis 值比较大，那么就需要作优化。
2. 如果docsExamined数很大，或者接近记录总数（文档数），那么可能没有用到索引查询，而是全表扫描。
3. 如果keysExamined数为0，也可能是没用索引。
4. 结合 planSummary 中的显示，上例中是 "COLLSCAN, COLLSCAN" 确认是全表扫描
5. 如果 keysExamined 值高于 nreturned 的值，说明数据库为了找到目标文档扫描了很多文档。这时可以考虑创建索引来提高效率。
6. 索引的键值选择可以根据 query 中的输出参考，上例中 filter:包含了 jzrq和jglxfldm 并且按照RsId排序，所以 我们的索引
索引可以这么建: db.f10_2_8_3_jgcc.ensureindex({jzrq:1,jglxfldm:1,RsId:1})
4.3 执行计划中的TYPE类型
COLLSCAN #全表扫描 避免
IXSCAN #索引扫描 可以改进 选用更高效的索引
FETCH #根据索引去检索指定document
SHARD_MERGE #将各个分片返回数据进行merge 尽可能避免跨分片查询
SORT #表明在内存中进行了排序（与老版本的scanAndOrder:true一致） 排序要有index
LIMIT #使用limit限制返回数 要有限制 Limit+（Fetch+ixscan）最优
SKIP #使用skip进行跳过 避免不合理的skip
IDHACK #针对_id进行查询 推荐,_id 默认主键,查询速度快
SHARDING_FILTER #通过mongos对分片数据进行查询 SHARDING_FILTER+ixscan最优
COUNT #利用db.coll.explain().count()之类进行count运算
COUNTSCAN #count不使用Index进行count时的stage返回 避免 这种情况建议加索引
COUNT_SCAN #count使用了Index进行count时的stage返回 推荐
SUBPLA #未使用到索引的$or查询的stage返回 避免
TEXT #使用全文索引进行查询时候的stage返回
PROJECTION #限定返回字段时候stage的返回 选择需要的数据, 推荐PROJECTION+ixscan