如何避免MongoDB由于全表扫描把所有Shard压垮_maxTimeMS防止请求雪崩

maxtimems 必须放在 cursor 选项中才能下推到每个 shard 执行层，直接传入 aggregate() 选项会被忽略；$group、$sort 等内存敏感阶段仍会先占满资源再超时，需配合 hint() 和索引优化。

为什么 maxTimeMS 不能直接加在聚合管道里就完事

很多人一看到“查询太慢压垮 Shard”，第一反应是给 aggregate() 加个 maxTimeMS 参数——但这是错的。mongodb 的 maxTimeMS 是作用在**整个命令生命周期**上的，包括计划阶段、分发阶段、结果合并阶段。一旦某个 Shard 上的扫描卡在锁等待或磁盘 IO，它可能根本没开始执行就超时，而其他 Shard 还在拼命扫，请求照样雪崩。

真正起效的位置是：必须显式传入命令级选项，且要确保它被下推到每个 Shard 的本地执行层。常见错误写法：db.Collection.aggregate([...], {maxTimeMS: 500}) —— 在分片集群中，这个值可能被忽略或仅作用于 mongos 协调层。

• 正确姿势：把 maxTimeMS 放进 cursor 选项里，例如 db.collection.aggregate([...], {cursor: {maxTimeMS: 500}})
• 更稳妥的做法是配合 hint() 强制走索引，否则即使设了 maxTimeMS，全表扫描仍会先消耗大量内存和 CPU 才触发超时
• 注意驱动差异：Node.js 的 mongodb 驱动 v4+ 要求 maxTimeMS 必须在 options 第二参数里，不能塞进 pipeline 或 cursor 对象内部

哪些聚合阶段会让 maxTimeMS 形同虚设

$group、$sort、$unwind 这些内存敏感阶段，会在单个 Shard 上累积大量中间数据。此时 maxTimeMS 只能杀掉整个操作，但无法阻止它已占满该 Shard 的工作集（working set），进而拖慢后续所有请求。

典型现象：mongos 日志里看不到超时错误，但 sh.status() 显示某 Shard 的 mem.resident 突增、extra_info.page_faults 暴涨，其他业务查询响应延迟翻倍。

• $sort 无索引时，即使加了 maxTimeMS，MongoDB 仍会尝试把全部匹配文档拉进内存排序，超时前已造成压力
• $lookup 如果被查集合没在本地 Shard 建好对应索引，会触发跨 Shard 查询 + 内存拼接，maxTimeMS 对网络等待无效
• 用 $facet 做多路聚合？每个子管道都独立计时，但资源占用是叠加的，一个子管道超时不代表整体释放资源

如何验证 maxTimeMS 真正生效到了每个 Shard

光看 mongos 返回是否报 MaxTimeMSExpired 不够。你得确认超时发生在 Shard 本地，而不是 mongos 层面假性中断。

最直接的方法：登录出问题的 Shard（不是 mongos），查它的日志。搜索关键词 operation exceeded time limit，并核对时间戳是否与业务请求吻合。如果只在 mongos 日志里看到 InterruptedAtShutdown 或空响应，大概率是没下推成功。

• 开启详细日志：在 Shard 的配置里加 setParameter: {logLevel: 1}，再复现一次慢查询
• 用 db.currentOp({secs_running: {$gt: 2}}) 在每个 Shard 上实时抓长任务，观察 secs_running 是否在接近 maxTimeMS 时归零
• 别依赖 explain("executionStats")：分片环境下它只返回 mongos 视角的估算，不反映各 Shard 实际耗时分布

maxTimeMS 和 collMod 限流不是一回事

有人试过给集合开 collMod + storageEngine 限流，以为能兜底。错了。maxTimeMS 是单请求熔断，而 collMod 的 background:true 或 indexBuildRetry:true 是针对建索引这类后台操作，对普通读写完全无效。

更关键的是：当多个慢查询同时触发 maxTimeMS 超时，它们的清理动作（比如释放内存、回滚游标）本身也会争抢锁，尤其在 WiredTiger 引擎下容易形成“超时风暴”——你本想防雪崩，结果制造了另一种雪崩。

• 真正兜底手段是前置控制：用 db.setProfilingLevel(1, {slowms: 100}) 抓出所有 >100ms 的查询，再逐个加 hint() 或改写
• 永远不要在生产分片集群上依赖 maxTimeMS 当性能优化手段，它只是最后一道保险丝
• 最容易被忽略的一点：maxTimeMS 的单位是毫秒，但某些旧版驱动（如 Python PyMongo 3.7 之前）会把它误当成秒处理，务必确认驱动文档里的单位约定