MongoDB在日常运维中，最让人头疼的场景之一就是实例响应突然变慢，CPU和内存占用飙升，但不知道是哪些操作在背后作祟。$currentOp正是为解决这类问题而生的工具，它作为聚合管道的一个阶段，能够返回当前实例上正在活动的所有操作信息，是排查慢查询、监控长事务和定位资源争抢的重要手段。本文将从语法入手，结合实际场景详细讲解它的使用方法。
一、$currentOp的基本语法与执行方式
$currentOp是MongoDB 3.6版本引入的聚合阶段，用于连接到admin数据库的聚合管道中，返回当前正在运行的操作快照。它替代并扩展了旧版的db.currentOp()方法，继承了聚合管道的灵活性，可以直接与$match、$project、$limit等阶段配合使用。
最基础的用法是切换到admin数据库后执行聚合命令，示例如下：
use admin
db.aggregate([
{ $currentOp: {} }
])
这个写法有几个细节需要注意。第一，必须使用db.aggregate()而不是db.collection.aggregate()，因为$currentOp不针对任何具体集合。第二，整个命令要求执行者具备inprog权限，普通用户默认无法查看其他用户的操作。第三，$currentOp阶段必须出现在管道的第一个位置，否则会报错。
该阶段支持几个重要的选项参数。allUsers设置为true时可以返回所有用户的操作，默认只返回当前连接自己的操作；idleConnections设置为true时会包含空闲连接的信息；idleCursors设置为true可以列出空闲游标；localOps则用于在分片集群的mongos上只返回本节点的操作。这些参数组合起来，可以灵活控制监控的范围和粒度。
一、$currentOp与db.currentOp()的区别
很多老版本的资料还在推荐db.currentOp()方法，但官方已经将其标记为废弃，本质上它只是一个包装了$currentOp的兼容层。理解两者的差异有助于写出更现代的运维脚本。
最大的区别在于过滤方式。db.currentOp()只能接受一个简单的文档作为过滤条件，功能单一；而$currentOp运行在聚合管道中，可以用完整的聚合表达式做过滤。比如你想找出所有执行时间超过1秒、且不是来自监控系统的操作，用管道写法会清晰得多。
另一个区别是输出处理能力。管道可以在$currentOp之后接$project阶段裁剪字段，只保留opid、secs_running、command等关键信息，避免输出大量无关字段干扰阅读；也可以接$sort按执行时间排序，接$limit控制返回条数。这种组合能力是旧方法完全不具备的。此外，分片环境下通过mongos执行时，$currentOp还能聚合多个分片节点的结果，监控视角更完整。
三、实战场景：排查慢操作并终止异常进程
生产环境中最典型的用法是过滤出长时间运行的写操作或聚合查询。下面这个管道会找出所有运行超过10秒、处于活跃状态的非空闲操作：
use admin
db.aggregate([
{ $currentOp: { allUsers: true, idleConnections: false } },
{ $match: {
active: true,
secs_running: { $gte: 10 },
waitingForLock: false
}},
{ $project: {
opid: 1,
secs_running: 1,
op: 1,
ns: 1,
command: 1,
client: 1,
appName: 1
}},
{ $sort: { secs_running: -1 } }
])
输出结果中，opid是操作的唯一标识，格式类似"shard01:200987"，单机环境下就是一个数字；secs_running表示已运行的秒数；ns是操作的命名空间；client记录了客户端地址；command则包含完整的命令内容，是判断问题语句的关键字段。如果应用在连接串中配置了appName，还可以通过它快速定位到具体的应用服务。
找到问题操作后，下一步通常是终止它。使用db.killOp()并传入opid即可：
db.killOp(opid)
需要注意的是，killOp并非立即生效，它是向目标操作发送一个中断标记，操作会在下一个可中断检查点退出。对于已经持有锁的操作，终止过程可能会有短暂延迟。另外，不要轻易终止索引构建这类后台任务，中断后需要重新执行，代价较大。
还有一种常见场景是排查阻塞事务。在4.0及以上版本中，可以通过过滤transaction字段找到多文档事务，观察lockStats字段可以判断哪些操作在等待锁，结合waitingForLock: true的条件，往往能发现持锁过久的事务源头。对于写冲突严重的情况，还可以关注planSummary字段，判断查询是否走了全表扫描。
四、使用中的注意事项与权限配置
首先是权限问题。执行包含$currentOp的聚合需要clusterMonitor角色或者自定义的inprog权限。如果只想终止操作，还需要killop权限。生产环境建议为运维账号单独创建角色，避免直接使用管理员账号操作。创建具备监控权限的角色的示例如下：
use admin
db.createRole({
role: "opMonitor",
privileges: [
{ resource: { cluster: true }, actions: [ "inprog", "killop" ] }
],
roles: []
})
其次是性能方面的考量。$currentOp本身执行很快，它读取的是内存中的操作快照，但在操作数极多的实例上，加上allUsers参数后返回的文档量可能非常大。建议始终在管道中配合$match尽早过滤，并用$project精简输出字段，避免把结果直接在客户端全量展开。
最后要提醒的是，$currentOp返回的是某一时刻的快照，不是持续监控。如果需要长期观察，可以将上述管道封装成定时脚本，按固定间隔采集并写入监控集合，再配合可视化工具绘制趋势。对于更完善的方案，可以结合数据库profiler和慢日志做离线分析，与实时监控形成互补。掌握$currentOp之后，面对实例异常时你就多了一双能够看透数据库内部运行状态的眼睛。
MongoDB聚合管道$currentOp数据库监控修改时间：2026-09-15 17:56:32