MongoDB 7.0 聚合引擎重写为 slot-Based，仅传递字段值（slot）而非完整文档，内存降40%+，$lookup 性能提升30%~50%（需索引），跨分片默认启用 atClusterTime 保证时间点对齐，不兼容操作符触发全链路回退至旧引擎。
7.0 的聚合执行引擎是重写的，6.0 仍是旧引擎；关键差异不在“快不快”，而在“传什么数据”——7.0 只传值（slot），6.0 必须传完整文档。
Slot-Based 引擎只传字段值，不是整个文档
旧引擎（6.0 及之前）每个聚合阶段都输出完整 BSON 文档，哪怕你只用 $group 统计一个 sum，中间结果仍包含所有原始字段；新引擎（7.0）只传递计算所需的“槽”（slot），比如 user_id 值、$sum(amount) 结果、$lookup 关联键等，不带无关字段。
- 内存占用可降 40%+，尤其对宽文档 + 多 stage 管道效果明显
-
$lookup性能提升 30%~50%，但前提是被关联集合有索引（如{ foreignField: 1 }），否则加速无效 - 含
$group、$sort、$project的管道受益最大；纯$match或$limit无感知
不支持的语法会自动回退到旧引擎
7.0 并非强制启用新引擎——遇到无法解析的操作符时，会静默降级，并在日志中记录：Query execution using legacy engine。
- 典型触发场景：管道中使用
$function、嵌套$let+$map混合、或自定义 JS 表达式 - 回退后性能回归 6.0 水平，且不再享受 slot 优化和跨分片时间点对齐
- 可通过
explain("executionStats")查看实际使用的引擎：executionStages.stage显示slotBasedExecution或classicExecution
聚合结果一致性在跨分片场景下有本质变化
6.0 跨分片聚合常出现“时间旅行”：不同 shard 返回的数据来自不同时间点，$group 结果可能漏统计或重复统计；7.0 默认启用 atClusterTime 机制，强制所有 shard 返回 ≤ 协调节点分配的逻辑时间戳的数据。
- 对金融报表、实时 BI 至关重要，但注意它只保证“不晚于”，不保证“精确等于”
- 若某 shard 复制延迟过大（oplog 堆积），可能报错：
ReadConcernMajorityNotAvailableYet，需检查该 shard 的replSetGetStatus中optime差值 - 6.0 无此机制，即使设
readConcern: "majority"，也无法约束跨 shard 时间点对齐
真正容易被忽略的是：slot 优化只在查询计划生成阶段生效，如果你的 pipeline 里混用了不兼容操作符，整条管道都会降级——不是部分 stage 用新引擎、部分用旧引擎，而是全链路回退。别只盯着 $group 写得漂亮，先确认 explain 输出里有没有 slotBasedExecution。
