MongoDB可通过maxTimeMS和maxMemoryUsageMB限制聚合资源，需绑定至自定义角色：maxTimeMS强制超时熔断，maxMemoryUsageMB拦截内存超限；二者须配合索引、分片与监控才有效。
如何用资源限制防止聚合查询吃光内存和CPU
MongoDB 本身不提供“禁止某用户执行 $group 或 $sort”这类细粒度权限控制，但可以通过资源配额机制让高开销聚合在触发前就被掐断——核心是启用 maxTimeMS 和 maxMemoryUsageMB，并绑定到角色级限制。
-
maxTimeMS是最直接的熔断开关：对所有聚合命令强制加超时，比如设为3000（3秒），超过即中断，避免慢查询堆积锁和连接 -
maxMemoryUsageMB（4.4+ 支持）能真正拦住内存爆炸：设为100，一旦聚合阶段（如$group）估算或实测内存超限，立即报错Exceeded memory limit for $group, but didn't allow external sort - 必须通过
db.createRole()绑定到自定义角色，再授给业务账号；不能只靠db.runCommand({setUserWriteBlockMode:...})这类全局开关 - 注意：
maxMemoryUsageMB对未命中索引的$lookup或无$match前置过滤的管道无效——它只限制“已进入管道的数据”的处理内存，不阻止全表扫描本身
为什么仅靠 read 权限无法防住聚合拖垮服务
默认的 read 角色允许执行任意 aggregate，哪怕只是 db.orders.aggregate([{$group:{_id:null,count:{$sum:1}}}]) 这种看似简单的统计，在2亿数据量下也会触发全集合扫描+内存聚合，瞬间打满CPU和RAM。
- MongoDB 的权限模型按“操作类型”（如
find、aggregate）授权，不区分“轻聚合”和“重聚合” - 即使禁用
aggregate权限，业务仍可能绕过：用mapReduce、或在应用层拉取全部文档后本地计算——这反而更耗网络和应用内存 - 真正有效的隔离是“让聚合能跑，但跑不过阈值”，而不是“不让跑”——否则监控告警、归档脚本等运维操作也会被误杀
线上配置 maxTimeMS 和 maxMemoryUsageMB 的实操要点
这两个参数必须通过角色定义写死，且需在 admin 数据库中创建；直接在 db.runCommand() 中传参只对单次调用生效，无法约束驱动自动发起的聚合。
- 创建受限角色示例：
db.runCommand({ createRole: "limitedAggReader", privileges: [{ resource: {database: "shop", collection: "orders"}, actions: ["find", "collStats"] }], roles: [], writeConcern: {w: "majority"} }) db.adminCommand({ setRolePrivilegesAndWeights: "limitedAggReader", privileges: [{ resource: {database: "shop", collection: "orders"}, actions: ["aggregate"] }], restrictions: { maxTimeMS: 3000, maxMemoryUsageMB: 100 } }) - 授予账号：
db.grantRolesToUser("biz_app", ["limitedAggReader"]) - 验证是否生效：用该账号执行一个长耗时聚合，会立刻收到
MaxTimeMSExpired或Exceeded memory limit错误，而非卡住或超时后才返回 - 坑点：如果聚合里用了
allowDiskUse: true，maxMemoryUsageMB将被忽略——务必禁止业务账号在聚合选项中传这个参数，可通过驱动层拦截或 mongos 代理过滤
配套必须做的三件事，否则资源限制形同虚设
光设参数不够，没监控、没索引、没分片，限制只会让错误从“慢”变成“快错”，问题依旧在线上爆发。
- 开启
system.profile并设为2（记录所有慢操作），重点过滤command.aggregate+executionStats.executionTimeMillis > 2000的日志，这是调优起点 - 确保每个高频聚合的
$match字段都有对应索引——否则maxTimeMS=3000只是把3分钟的卡顿变成3秒的失败，根本没解决扫描量大的问题 - 若单集合超5千万文档，必须评估分片；否则即使加了限制，所有聚合请求仍挤在同一个
mongod上争抢CPU和锁，maxTimeMS触发频率会越来越高
