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 之前）会把它误当成秒处理，务必确认驱动文档里的单位约定
