缓存查询计划？答案

【问题标题】：Cached Query plans?缓存查询计划？
【发布时间】：2012-04-04 16:11:48
【问题描述】：

查询计划存储在视图和普通的计划缓存中 SQL

来自here

好的。

一劳永逸：它对我有什么帮助？

即使我在cache 中有Query plans 用于查询：一旦我运行查询他将扫描整个表/s + 聚合+....。

如果我明天运行它 - 它将再次扫描整个表/s + 聚合 ....

不可能有这样的情况：“啊！！！我有数据在缓存中，所以我会从那里取出它.......（因为可能表有变了……）

那么，真正的好处在哪里？

我好像漏掉了什么。

谢谢。

【问题讨论】：

【解决方案1】：

假设我们有一个查询，例如

SELECT *
FROM 
    A 
    INNER JOIN B ON -- omitted
    INNER JOIN C ON -- omitted
    -- omitted
    INNER JOIN Q ON -- omitted

不管有多少表。显然，这些连接的执行顺序会影响性能。此外，在给定表格统计信息的情况下，确定最佳顺序也需要一定的时间。

通过缓存查询计划，我们只需一次支付确定最佳顺序的成本 - 以后每次运行查询时，我们已经知道要先取K，加入E，然后加入H，依此类推。

当然，这意味着数据统计的重大变化会使我们的计划无效，但缓存任何东西总是需要权衡取舍。

SQL Coach 是您可能会发现有助于了解更多关于查询计划的方法和原因的资源 - 从 THE Analogy 开始。

【讨论】：

【解决方案2】：

答案是查询计划被缓存，以防止每次编译查询计划的成本。第二次运行查询（或另一个可以使用相同计划的查询）时，它不需要重新运行编译过程，它只是从缓存中提取计划。

【讨论】：

【解决方案3】：

简而言之，执行计划是对如何完成查询的说明，而不是查询中涉及的实际数据（因此，当您重新运行查询时，可以反复应用执行计划）。

一个类比是说执行计划类似于食谱 - 它是获取数据/制作膳食的方法，而不是数据/膳食本身。

改进之处在于数据库引擎需要时间来制定查询的执行计划，所以如果它被缓存了，下次运行相同的查询时就不需要这种开销了。

【讨论】：

【解决方案4】：

当您向 SQL 提交查询时，它会通过一些步骤来显示结果。主要的有解析器、algebrizer 和查询优化器。

查询优化器负责构建执行计划，或者从缓存中选择一个执行计划，据我所知，构建计划的过程非常昂贵，因此如果您可以重用一个执行计划会更好。

主要的一点是执行计划不包含数据本身，只是从 BD 中检索数据的一种方式。因此，一旦“定义”了计划，它就会被传递给存储引擎并用于检索数据。

【讨论】：