MongoDB 7.0 不支持跨分片场景启用 Slot-based 查询执行引擎，该引擎仅适用于单一分片（副本集或未分片集合），分片聚合默认回退至经典引擎；真正影响性能的是 mongos 层优化，如 $mergeCursors 并行归并、分片键驱动的 $match 下推及 writeConcern 配置。
MongoDB 7.0 并不支持跨分片场景下启用 Slot-based 查询执行引擎——这是关键前提，直接决定你调优方向是否跑偏。
为什么 $group 或 $lookup 在分片集合上仍走经典引擎
Slot-based 查询执行引擎在分片集群中默认被禁用，即使查询本身符合资格（如含 $group、$lookup），只要目标集合是分片的，MongoDB 就会自动回退到经典引擎，并可能记录警告：Query execution using legacy engine。这不是配置遗漏，而是设计限制：
- 该引擎目前仅在单一分片（即副本集或未分片集合）上启用；分片路由层（
mongos）与 Slot-based 执行器之间尚无集成路径 - 官方文档明确说明：Slot-based 引擎“适用于从 MongoDB 5.1 开始的某些查询”，但从未声明其支持跨分片聚合调度
- 7.0.17 起，该引擎在所有 7.0 补丁版本中默认关闭；若你正用 7.0.x（非 8.0），它大概率根本没在跑
真正影响跨分片聚合性能的其实是 mongos 层优化
别盯着 Slot-based，分片聚合提速的关键在 mongos 如何协调、合并和流式处理各 shard 的结果。6.0 起已落地、7.0 持续强化的机制才是实际生效点：
-
$mergeCursors隐式启用：mongos 并行拉取各 shard 结果，边收边归并，避免串行等待全部返回再排序 - maxTimeMS 在分片层传播更可靠：超时中断更快，防止某个慢 shard 拖垮整条管道
- aggregation pipeline 支持在 mongos 层过滤变更流事件：减少冗余数据跨分片广播，间接降低聚合压力
- 连接池 idle timeout 和 max pool size 自适应：避免长连接堆积导致路由延迟升高
如何验证当前聚合是否用了 Slot-based 引擎
别猜，用 explain("executionStats") 看真实执行路径：
- 如果输出里出现
"executionStages": { "stage": "SLOT_BASED_EXECUTION" }，说明命中了（但几乎只会在非分片集合上） - 更常见的是看到
"stage": "SHARD_MERGE"或"stage": "SINGLE_SHARD"，这代表 mongos 正在协调分片，与 Slot-based 无关 - 若日志中出现警告
Query execution using legacy engine，不是你写错了，而是当前上下文（分片+版本）不满足启用条件
想让跨分片聚合变快，优先检查这三件事
Slot-based 引擎现阶段对分片用户只是“背景板”，真正卡脖子的往往是基础配置和查询结构：
- 确保
$match阶段严格以分片键开头（如{ shardKey: "val", timestamp: { $gte: ... } }），否则 mongos 只能 fan-out 到全部 shard - 避免在聚合开头用
$lookup关联非分片集合——这会强制所有分片都发起远程请求，放大网络开销 - 确认
writeConcern是"majority"（7.0 默认）：防止因元数据陈旧引发StaleConfig错误重试，间接拖慢聚合启动
Slot-based 引擎的潜力在单分片复杂聚合里确实明显，但跨分片场景下，它的缺席是事实。与其纠结怎么“打开”它，不如先盯紧分片键设计、mongos 版本、以及聚合阶段顺序——这些才是真正左右响应时间的杠杆。8.0 虽然默认启用 Slot-based，但分片支持仍无官方路线图，这点容易被宣传话术带偏。
