mongodb 7.0通过默认启用slot-based查询引擎优化大型聚合，$group和$lookup变快是因为新引擎只传递必要“槽”（如user_id或$sum结果），避免旧引擎反复序列化完整文档，内存降40%+，$lookup提速30%~50%（需被关联集合有索引）。
MongoDB 7.0 对大型聚合查询的优化不是靠手动调参实现的，而是默认启用 Slot-Based 查询引擎，只要聚合管道符合要求，加速就自动生效。
为什么 $group 和 $lookup 在 7.0 里变快了
旧引擎（6.0 及之前）对每个阶段都做完整文档序列化：比如 $group 输出带全部字段的文档 → $project 再删字段 → 反复序列化/反序列化，中间结果体积大、内存占用高。7.0 的 Slot-Based 引擎只传递计算所需的“槽”（如 user_id 值或 $sum(amount) 结果），不带无关字段。实测内存占用可降 40%+，$lookup 性能提升 30%~50% —— 但前提是被关联集合有对应索引，例如 { foreignField: 1 }。
常见错误现象：明明用了 7.0，$lookup 却没提速 → 查日志是否出现 Query execution using legacy engine；若出现，说明管道含不支持语法（如嵌套 $function），引擎自动回退。
哪些聚合写法会触发旧引擎回退
Slot-Based 引擎不支持所有语法，遇到以下情况会静默降级：
-
$function出现在非顶层或嵌套位置（如$map内部） -
$accumulator自定义累加器未声明兼容性标识 -
$facet中某个分支含不支持操作，整个$facet降级 -
$merge或$out后接复杂表达式（如带$let的字段重命名）
验证方式：开启慢查询日志，过滤含 "executionStats" 的条目，检查 executionStages.executionEngine 字段值是 "slotBased" 还是 "classic"。
analyzeShardKey 能提前暴露聚合瓶颈
很多聚合慢，根源不在管道本身，而在分片键设计不合理——比如用时间戳做前缀，导致 $group 需跨几乎所有分片拉数据。7.0 的 db.collection.analyzeShardKey() 可采样评估读写分布：
- 启用
readWriteDistribution: true，它会报告写入倾斜度（如 95% 写入集中到单一分片） - 结合
sampleRate: 0.1和sampleSize: 10000控制采样开销 - 输出中重点关注
writeDistribution.skew和readDistribution.hotspots字段
注意：该命令仅分析现有数据分布，不修改集群；但若发现严重倾斜，需重建分片键并迁移，不能仅靠优化聚合语句补救。
跨分片聚合终于能对齐时间点
旧版本跨分片执行 $sort + $limit 时，各 shard 返回数据时间点不一致，结果可能漏掉最新几秒的记录。7.0 的 atClusterTime 机制强制所有参与分片返回 ≤ 协调节点分配的逻辑时间戳的数据：
- 对金融对账、实时看板类聚合至关重要
- 不保证“精确等于”，只保证“不晚于”；若某 shard 复制延迟过高（如 oplog 堆积），会直接报错
ReadConcernMajorityNotAvailableYet - 可通过
db.adminCommand({ "setFeatureCompatibilityVersion": "7.0" })确保全集群启用该机制
真正容易被忽略的是：这个时间点对齐只作用于读操作，$merge 或 $out 写入目标集合时，仍按各分片本地时间提交，不参与 atClusterTime 协调。
