Oracle 执行计划成本与速度答案

【问题标题】：Oracle execution plan cost vs speedOracle 执行计划成本与速度
【发布时间】：2013-04-15 15:01:28
【问题描述】：

在 Oracle 中构建和调整查询时，速度通常是开发人员主要关心的问题。但是，在调整特定查询时，我最近尝试了 FIRST_ROWS 和 NO_CPU_COSTING 提示，生成的执行计划在执行时间上比之前的计划快 80%，但成本高出 300%。执行计划中的 I/O 非常少，而且所有额外开销似乎都来自两个视图之间的嵌套循环外连接。

这个查询是分页的，所以我只需要前几百行。缺乏重要的 I/O 使我认为这个查询不会依赖于缓存，乍一看似乎是要走的路。但是，由于我从未见过查询的速度提高和同时成本如此之高，我不确定使用此查询可能有什么缺点。有吗？

【问题讨论】：

您提到的两个提示是非常面向嵌套循环的 - NL 对于检索前 N 行很有用，而且对于非常便宜的 CPU 而言，这是一种非常简单的方法。另一种选择是例如合并排序 - 主要用于连接两个大表。它的 CPU 很昂贵，因为它需要排序。散列连接也是 CPU 昂贵的，因为它需要应用散列函数。我不具体了解您的情况，但大多数系统都受磁盘限制而不是 CPU 限制，因此减少磁盘读取量会降低成本。
其实我觉得准确性比速度更重要。
我曾在一个表中有超过 500,000 行的系统上工作过。我认为速度是必须的，否则会损害整个系统。
您的意思是在获取所有行时，还是在获取第一个屏幕时，它的速度提高了 80%？如果只获取第一个屏幕，那么这完全符合预期 - 完整查询的总成本更高，但前几行的经过时间更短。
@TonyAndrews 查询本身是分页的，所以resulset比较小，最坏的情况下不到几百行。

标签： sql performance oracle query-optimization sql-execution-plan

【解决方案1】：

这是一个非常典型的查询，当需要完整的数据集时，使用 equijoin 优化以使用哈希连接，而当只需要前几行时使用嵌套循环，或者排序用于按完整日期集排序，其中索引可以更有效地用于子集。

当然，如果优化器不知道您只会使用行的子集，那么它不会给出您实际执行的查询的成本，因为它包括所有嵌套循环操作的成本永远不会执行。

但是，估计的成本并没有错，就是这样。如果您想要一个更有意义的数字以供您自己理解，请使用 rownum 限制。

顺便说一句，FIRST_ROWS 已被弃用，取而代之的是 first_rows(1)、first_rows(10)、first_rows(100) 或 first_rows(1000)。

【讨论】：

你是对的！显然，这并没有出现在我正在查看的 Oracle 页面上，但 FIRST_ROWS 提示确实已被弃用。但是，您引用的是 OPTIMIZER_MODE 设置。 FIRST_ROWS 提示已被弃用，取而代之的是 FIRST_ROWS(n)。我切换到 FIRST_ROWS(1)，计划显示出更合理的成本。如果你会更新你的答案，我会接受它:)