查询计划
最后更新于
最后更新于
在本页面
对于查询，MongoDB查询优化器在给定可用索引的情况下选择并缓存效率最高的查询计划。最有效的查询计划的评估是基于查询执行计划在查询计划评估候选计划时执行的“工作单元”(works)的数量。
关联的计划缓存条目用于具有相同查询形状的后续查询。
从MongoDB 4.2开始，缓存条目与状态关联：
有关触发对计划缓存进行更改的其他方案，请参阅。
要查看给定查询的查询计划信息，可以使用 或。
从MongoDB 4.2开始，您可以使用 聚合阶段来查看集合的计划缓存信息。
索引或收集删除之类的目录操作会清除计划缓存。
最近最少使用（LRU）高速缓存替换机制将清除最近最少访问的高速缓存条目，而不管其状态如何。
用户还可以：
也可以看看
[success] 注意
与任何hash函数一样，两个不同的查询形状可能会导致相同的hash值。但是，不同查询形状之间不会发生哈希冲突。
planCacheKey 是与查询关联的计划缓存条目的键的hash值。
[success] 注意
与queryHash不同，planCacheKey是查询形状和当前可用的形状索引的函数。也就是说，如果添加/删除了支持查询形状的索引，planCacheKey值可能会改变，而queryHash值不会改变。
例如，考虑一个具有以下索引的foo集合:
集合上的以下查询具有相同的形状:
如果删除了其中一个索引，或者添加了一个新的索引**{x: 1, a: 1}，那么用于这两个查询操作的planCacheKey**将会改变。
queryHash和planCacheKey是可用的在:
**PlanCache.listQueryShapes()**方法/planCacheListQueryShapes命令
**PlanCache.getPlansByQuery()**方法/planCacheListPlans命令
索引筛选器确定优化器为查询形状评估哪些索引。查询形状由查询、排序和投影规范的组合组成。如果存在针对给定查询形状的索引筛选器，则优化器仅考虑筛选器中指定的那些索引。
索引过滤器仅影响优化器评估的索引；对于给定的查询形状，优化器仍然可以选择将集合扫描作为获胜计划。
索引过滤器在服务器进程的持续时间内存在，并且在关闭后不会持续存在。MongoDB还提供了手动删除过滤器的命令。
也可以看看：
译者：杨帅
校对：杨帅
缓存中不存在此形状的条目。 对于查询，如果形状的缓存条目状态为 ： 1.对候选计划进行评估并选出一个获胜的计划。 2.所选计划将以非活动状态及其工作值添加到缓存中。。
缓存中的条目是此形状的占位符条目。也就是说，计划者已经看到了形状并计算了其成本（works价值）并存储为占位符条目，但查询形状不用于生成查询计划。 对于查询，如果形状的缓存条目状态非： 1.对候选计划进行评估并选出一个获胜的计划。 2.所选计划的工作值与非活动条目的工作值进行比较。如果所选计划的works值为：小于或等于条目的， 所选计划将替换占位符“不 条目，并具有“ 状态。 如果在替换发生之前，“ 条目变为“ (例如，由于其他查询操作)，则仅当新活动条目的works值大于所选计划时，才会替换该新活动条目。 大于非条目的数量， 不的条目仍然存在，但其工作值增加。
缓存中的条目用于中奖计划。计划者可以使用该条目来生成查询计划。 对于查询，如果形状的缓存条目状态为 ： 活动条目用于生成查询计划。 计划者还评估条目的性能，如果条目的 works值不再符合选择标准，它将转换为非状态。
如果 重新启动或关闭，查询计划缓存将不会保留。此外：
使用方法手动清除整个计划缓存 。
使用方法手动清除特定的计划缓存条目 。
为了帮助识别具有相同的慢速查询，从MongoDB 4.2开始，每个查询形状都与一个相关联。queryHash是一个十六进制字符串，表示查询形状的散列，并且只依赖于查询形状。
为了更深入地了解，MongoDB 4.2引入了 .
对于这些查询，带有 的索引可以支持查询操作2，但不支持查询操作1。由于支持查询操作1的索引与查询操作2不同，这两个查询具有不同的planCacheKey。
字段： 和
记录慢查询时， 和。
聚合阶段（MongoDB 4.2中的新增功能）
当存在查询形状的索引过滤器时，MongoDB会忽略。要查看MongoDB是否为查询形状应用了索引筛选器，请检查或 方法的字段。
因为索引过滤器会覆盖优化器和方法的预期行为，所以请谨慎使用索引过滤器。
见， 和。