$facet在大数据量下易触发exceededmemorylimit错误，因其不支持磁盘溢出、强制全量复制输入文档、无法索引优化、子管道隔离导致重复计算，且分片集群中引发广播查询；应优先使用预聚合、前置$match或拆分查询替代。
为什么$facet在大数据量下容易触发ExceededMemoryLimit错误
$facet阶段不支持磁盘溢出（allowDiskUse: true无效），所有子管道必须在内存中完成计算。每个子管道都接收**完整输入文档集**，不是流式处理——哪怕你只想要两个简单计数，MongoDB也会把全部匹配文档复制多份，分别喂给每个子管道。当原始数据集达百万级、单文档平均2KB时，仅输入复制就可能突破100MB内存上限，直接抛出ExceededMemoryLimit错误。
$facet放在管道开头会强制全表扫描
如果$facet是聚合管道第一个阶段，MongoDB无法利用索引加速，只能执行COLLSCAN。常见误写如：db.orders.aggregate([ { $facet: { ... } } ])，哪怕后面跟$match也无用——因为$facet已先把全集合读进内存。正确做法是把$match提到最前面，确保先过滤再进$facet：
db.orders.aggregate([
{ $match: { region: "cn", createdAt: { $gte: ISODate("2026-07-01") } } },
{ $facet: { ... } }
])
聚合子管道之间完全隔离，无法复用中间结果
$facet内每个子管道都是独立执行环境，彼此看不到对方输出。比如你想同时统计“订单总数”和“近7天订单占比”，不能让第二个子管道复用第一个的总数结果，而是各自重新遍历一遍输入文档。这导致CPU和内存开销线性叠加。更隐蔽的问题是：若子管道都含$group，它们各自的分组键若未对齐分片键，还可能触发Scatter-Gather广播查询，进一步放大延迟。
替代方案比硬扛$facet更实际
- 用预聚合表代替实时
$facet：对高频维度（如region+status+day）每天凌晨跑一次aggregate写入汇总表，查询时直接find - 拆成多次独立查询：前端或服务层并发请求多个
$count或$group，比单次$facet更可控 - 避免在分片集群上用
$facet做跨分片统计：它天然不支持Targeted Query，必然广播到所有分片
真正卡住性能的往往不是语法本身，而是默认假设“一份数据能同时喂给多个管道”——而现实里，这份“同时”代价极高，且无法通过加内存绕过。
