根本原因是聚合写法不当：$match未前置、$project未精简字段、$sort/$group过早执行；allowDiskUse=True须为顶层参数、服务端版本支持且部署环境允许，否则仍报错。
Python 调用 MongoDB 聚合管道报 Sort exceeded memory limit 或 Exceeded memory limit for $group，根本原因不是数据量太大，而是聚合写法让 MongoDB 在内存里扛了不该扛的文档——尤其是没前置 $match、没精简字段、$sort/$group 过早执行。
为什么 PyMongo 里加了 allowDiskUse=True 还报错？
常见误区是以为只要传参就万事大吉。实际有三个硬性前提必须同时满足：
-
allowDiskUse=True必须作为aggregate()方法的**顶层参数**，不能塞进 pipeline 列表里，也不能漏掉（比如只写了{'allowDiskUse': True}却没传给方法） - MongoDB 服务端版本得支持：6.0+ 默认开启磁盘排序（
allowDiskUseByDefault=true），但 5.x 及更早版本必须显式传allowDiskUse=True，否则直接拒绝 - 部署环境得允许：MongoDB Atlas M0 免费集群**完全禁用
allowDiskUse**，无论 PyMongo 怎么传都无效；Docker 容器里如果/tmp是内存盘（tmpfs），磁盘空间不足也会静默失败
$match 必须放在 pipeline 最前面，且字段要带索引
MongoDB 只有第一个 $match 阶段能下推到存储层走索引扫描，后面的 $match 全是内存过滤，不减少 I/O 和内存压力。
- 错误写法：
[{"$group": {...}}, {"$match": {"total": {"$gt": 10000}}}]—— 分组已完成，内存早满了 - 正确写法：
[{"$match": {"status": "completed", "created_at": {"$gte": ISODate("2026-01-01")}}}, {"$group": {...}}] - 索引必须匹配：如果
$match用{shop_id: 1, created_at: {$gte: ...}}，就得建复合索引db.orders.createIndex({shop_id: 1, created_at: 1})，单字段索引无效
$project 不是可选项，是内存控制开关
哪怕你最终只想要一个 count，只要 pipeline 中某处出现过 {"content": 1}，MongoDB 就会把几 MB 的文本字段从每个分片拉到 mongos 内存里，再丢弃。
立即学习“Python免费学习笔记（深入）”；
- 聚合前加
$project显式裁剪：{"_id": 0, "user_id": 1, "amount": 1, "updated_at": 1} - 绝对不要
{"content": 1}后接{"$match": {"content": /xxx/}}—— 正则匹配必须在$project之后做，且最好用$regex+ 索引字段 - 想统计文本长度？用
{"len": {"$strLenCP": "$content"}}，别把原文本拖进来
PyMongo 实操时容易被忽略的细节
真正卡住人的，往往不是原理，而是驱动层和部署环境的隐性约束：
-
cursor参数别漏：聚合返回游标，大结果集务必加cursor={"batchSize": 1000}，否则 PyMongo 默认一次拉光，mongos 内存直接爆 - 查中间体积：在 shell 里用
explain("executionStats")看executionTimeMillisEstimate和usedDisk字段，确认是否真用了磁盘 - 单文档超限会掩盖问题：用
Object.bsonSize(doc)测原始文档或$project后中间结果大小，接近16777216就得拆 -
$graphLookup阶段严格限制 100MB 内存，allowDiskUse对它完全无效，必须重设计逻辑
