maxTimeMS是MongoDB服务端强制中断参数，仅作用于主节点聚合执行过程，需作为aggregate()顶层选项传入，超时触发MaxTimeMSExpired错误。
聚合查询中 maxTimeMS 是服务端强制中断参数，不是客户端超时设置
maxTimeMS 是 MongoDB 服务端执行层面的硬性限制，由 mongod 在执行阶段主动中止长时间运行的聚合操作。它不依赖网络层或驱动配置，也不受 socketTimeoutMS 或 connectTimeoutMS 影响。一旦触发，服务端直接返回 MaxTimeMSExpired 错误，驱动抛出 ExecutionTimeout（PyMongo）或类似异常（Node.js 驱动为 MongoServerError with code 262）。
在聚合管道中正确传入 maxTimeMS 参数的位置
必须作为顶层选项传给 aggregate() 方法，不能放在 pipeline 数组内部，也不能设在会话或客户端连接配置里：
db.orders.aggregate([
{ $lookup: { from: "customers", localField: "customerId", foreignField: "_id", as: "customer" } },
{ $unwind: "$customer" }
], {
<strong>maxTimeMS: 5000</strong>
})
- Node.js 驱动示例：
collection.aggregate(pipeline, { maxTimeMS: 5000 }) - PyMongo 示例：
collection.aggregate(pipeline, maxTimeMS=5000) - 错误写法：
pipeline.push({ $maxTimeMS: 5000 })（语法无效） - 错误写法：
client = MongoClient(..., socketTimeoutMS=5000)（不影响聚合执行时间）
副本集环境下 maxTimeMS 的实际行为差异
在副本集上，maxTimeMS 仅作用于主节点（primary）的执行过程。从节点（secondary）不参与聚合计算，因此不会触发该限制；但如果读请求带 readPreference=secondary 并启用 allowDiskUse 等需本地计算的选项，仍可能因资源不足提前失败——但这与 maxTimeMS 无关。
- 若聚合涉及大量磁盘排序（
$sort+$group），建议同时加allowDiskUse: true，否则可能因内存超限被 kill，错误码为 16819（QueryExceededMemoryLimitNoDiskUseAllowed） - 副本集选举期间，正在执行的聚合可能被中断并报
Interrupted（代码 11601），这不是maxTimeMS触发的 -
maxTimeMS不保证精确到毫秒级中断，通常有 ±100ms 左右的调度延迟
调试和验证 maxTimeMS 是否生效的实操方法
最直接的方式是构造一个可控慢查询，观察是否在指定时间内终止：
db.slowtest.aggregate([
{ $addFields: { x: { $range: [0, 1000000] } } },
{ $unwind: "$x" },
{ $group: { _id: null, total: { $sum: "$x" } } }
], { maxTimeMS: 1000 })
- 用
db.currentOp({ "secs_running": { $gt: 0.5 } })查看是否残留长运行操作（正常应无） - 检查日志：开启
verbosity: 1后，maxTimeMS中断会在 mongod 日志中留下"operation was interrupted due to maxTimeMS"字样 - 注意：如果聚合已进入 commit 阶段（如写入目标集合），
maxTimeMS不会中止写入，只中断计算过程；此时可能产生部分写入结果
真正难控制的是事务内聚合——maxTimeMS 可用于单个聚合命令，但无法延长事务整体生命周期（仍受 transactionLifetimeLimitSeconds 约束）。这两个机制各自独立，容易混淆。
