MongoDB 6.0 并未引入SlotBased执行引擎，其查询执行器始终为树形结构；所谓“SlotBased”是误传，源于混淆PostgreSQL模型、CatalogCache或WiredTiger页内slot。
SlotBased执行引擎和查询计划缓存的关系
MongoDB 6.0 并没有引入所谓“SlotBased执行引擎”——这是混淆了 PostgreSQL 的执行模型。MongoDB 的查询执行器始终基于经典的树形执行器（tree-based executor），不使用 slot、tuplestore 或向量化执行单元。所谓“SlotBased”在 MongoDB 官方文档、JIRA、源码仓库（如 src/mongo/query/）或 6.0 release notes 中完全不存在。
为什么你会看到“SlotBased”这个词被误传
常见误传来源有三类：
- 把 PostgreSQL 的
ExecProcNode/Slot模型套用到 MongoDB，尤其在对比 SQL vs NoSQL 执行机制的二手博客里高频出现； - 将 MongoDB 6.0 新增的
CatalogCache（目录缓存）机制，错误类比为“类似执行槽位的元数据占位”，但 CatalogCache 纯属分片路由层的元数据缓存，和查询执行计划无关； - 把 WiredTiger 存储引擎内部的 page slot（页内插槽）结构，张冠李戴到查询执行层。
真正影响查询计划缓存行为的 6.0 变动
MongoDB 6.0 对查询计划缓存本身没有结构性重写，但以下改动会间接影响缓存命中与刷新逻辑：
-
setIndexCommitQuorum命令变更：索引构建确认策略调整后，DDL 事件（如createIndex）更易触发计划缓存清空，因为索引可用性判断逻辑更严格； - 时间序列集合（
timeSeries）支持测量字段索引：新增索引类型导致查询形状（query shape）识别更敏感，相同语义的查询若混用metaField和非metaField过滤条件，会被视为不同 shape，无法共享缓存； - 索引格式升级至 V2（版本号 14）：键字符串（
KeyString）编码变更，可能导致旧缓存条目在升级后首次查询时被判定为失效，触发重新规划； -
$planCacheStats聚合阶段返回字段新增cacheEntryStatus，可明确看到"active"/"inactive"/"missing"状态，方便诊断为何某查询没走缓存。
排查缓存未命中的实际操作建议
别猜“引擎变了”，直接查状态和形状：
- 用
db.collection.explain("executionStats")查当前查询是否用了缓存计划（看queryPlanner.winningPlan.stage是否含"IXSCAN"且无"stage: 'SUBPLAN'"类兜底行为）； - 运行
db.collection.getPlanCache().list()，比对输出中queryHash和你实际查询的explain().queryPlanner.queryHash是否一致； - 注意
explain()本身会绕过缓存——它强制重规划，所以不能靠它判断“线上是否命中”，只能用$planCacheStats或慢日志里的planSummary字段； - 如果应用用的是带参数的驱动查询（如 Node.js 的
{ status: req.query.status }），确保参数值类型一致（"1"和1是不同 shape），否则缓存条目无法复用。
真正容易被忽略的点是：缓存条目的“活性”不是永久的，一个 "active" 条目可能在连续几次慢查询后自动降级为 "inactive"，而这个过程没有任何日志提示，只能靠定期 list() 观察。
