必须为聚合管道显式设置maxTimeMS作为顶层选项，它是服务端强制终止的精确毫秒上限，超时抛出相应错误，且作用于整个管道包括$lookup、$sort等阶段；盲目使用db.killOp()风险高，生产环境优先采用Atlas查询拒绝过滤器。
直接用 maxTimeMS 设置硬性超时，比事后 db.killOp() 更可靠、更安全。 因为聚合任务一旦发起，客户端断连或超时不会让服务端自动中止；不加限制的 $lookup、$sort 或全表扫描可能持续占用 CPU 和锁资源，甚至拖垮整个分片节点。
聚合管道里必须显式加 maxTimeMS
它不是“建议执行时间”，而是服务端强制终止的精确毫秒上限。超过即抛 MaxTimeMSExpired 错误（Node.js 驱动）或 ExecutionTimeout（PyMongo），且作用于整个管道——包括所有 $lookup 关联、$group 分组、$sort 排序阶段。
-
maxTimeMS必须作为聚合命令的顶层选项传入，不能只写在某个 stage 里 - 例如：在 mongosh 中运行
db.orders.aggregate([ { $match: { status: "pending" } }, { $group: { _id: "$region", total: { $sum: "$amount" } } } ], { maxTimeMS: 5000 }) - 驱动层调用也要带该参数：PyMongo 的
collection.aggregate(pipeline, maxTimeMS=5000)，Node.js 的collection.aggregate(pipeline).maxTimeMS(5000) - 注意：如果管道里有
$out或$merge这类写操作，maxTimeMS仍生效，但中断时可能留下部分写入结果（非原子）
查不到 opId 就别乱用 db.killOp()
盲目调用 db.killOp() 容易误杀系统内部操作（比如复制、均衡器迁移），尤其在分片集群中，killOp 不会传播到写操作所在的分片，只对读操作有效。
- 先在
admin库跑db.currentOp({ "secs_running": { $gt: 30 }, "active": true })找出运行超 30 秒的活跃操作 - 重点过滤字段：
ns（命名空间）、command.aggregate、secs_running、type: "operation"，避免匹配到op: "command"类型的后台任务 - 确认是目标聚合后，再执行
db.killOp(<opid>)；若在 mongos 上操作，需确保localOps: true且查询发自同一 mongos - 分片集群中写操作要终止，得用
killSessions配合lsid，而不是killOp
生产环境优先用 Atlas 的操作拒绝过滤器
MongoDB 8.0+ Atlas 控制台可直接拦截已知慢查询结构，比每次手动 kill 更治本——特别是当某类聚合因缺失索引反复触发高 CPU 时。
- 进入 Atlas → Cluster → Query Profiler，找到高频超时的聚合语句
- 点击「Reject」按钮，输入匹配条件，如
{ "command.aggregate": { "$exists": true }, "command.pipeline.0.$sort": { "$exists": true } } - 过滤器生效后，同类请求直接返回
QueryExceededMemoryLimitNoDiskUseAllowed或MaxTimeMSExpired，不进执行队列 - 修复完查询（比如补上索引、拆分大
$lookup）后再在 Atlas 中「Re-enable」
真正难处理的不是单次超时聚合，而是没设 maxTimeMS 又没监控的长周期聚合——它可能卡住 WiredTiger 的文档级锁，阻塞其他写入，而你从 currentOp 里看到的 secs_running 还在缓慢上涨。所以，上线前必须把 maxTimeMS 当成聚合的必填项，而不是备选方案。
