Performance Oracle性能—从最小的结果集开始是否更好

只是和一些同事讨论一下编写查询和性能的最佳方法

限制第一个结果集是否更好，以便初始表中的所有联接都有更少的行可联接

例如：

表：REFCODE约有10000行

表：WHSE约有200行

哪一种性能更好

使用内部联接从大型结果集中挤出行：

SELECT
  *
FROM
  REFCODE
INNER JOIN
  WHSE ON
  WHSE.RCIDX = REFCODE.RCIDX

首先使用较小的结果集：

SELECT
  *
FROM
  WHSE
INNER JOIN
  REFCODE ON
  REFCODE.RCIDX = WHSE.RCIDX

使用最大的resultset，但使用where子句，筛选器只记录我知道将连接到第二个表的记录

SELECT
  *
FROM
  REFCODE
INNER JOIN
  WHSE ON
  WHSE.RCIDX = REFCODE.RCIDX
WHERE
  REFCODE.TYPE = 'WHSE'

或者国会预算办公室会决定类似的解释计划吗？ 这里的同事告诉我，你应该从尽可能小的结果集开始，但不确定

---

任何讨论都有可能

对于您发布的一个简单案例，优化器几乎肯定会为所有三个查询生成相同的查询计划。性能不会有任何差异

通常，查询中表的顺序是不相关的。优化器应该根据您收集的对象统计信息，确定适当的连接顺序和连接方法。有时，当您加入相对较大的表时，优化器将无法考虑每一个可能的连接顺序，因为这样做将需要超过优化器-Max置换（< /代码>设置）。当发生这种情况时，优化器使用试探法来确定要详细考虑哪些路径和忽略哪些路径。这些启发式算法是不完美的，因此您可能会发现，在某些情况下，优化器会消除一条可能导致更好的连接顺序的路径。首先列出限制性最强的表格可能会产生对计划的偏见，因为这是最有效的驱动表格。但这在很大程度上是一个极端情况

乔纳森·刘易斯（Jonathan Lewis）写了一篇很好的文章，讲述了该如何做。但是对于您可能编写或遇到的绝大多数查询，表的顺序是不相关的

在旧的基于规则的优化器时代，当Oracle 7.3.4焕然一新，恐龙在地球上漫游时，基于规则的优化器将使用表的顺序生成计划。我敢打赌，你正在与之交谈的人要么已经足够大了，在那些日子里，要么正在传承那些老开发人员教给他们的规则

---

尽管（在几乎所有情况下）不再有任何性能优势，但构建查询结构的一致性方法可能是有益的。例如，如果总是将前导表放在第一位，这可能会鼓励开发人员考虑预期的查询计划，并更加深思熟虑地编写代码。而且，当优化器生成查询计划时，它可以相对快速地查看优化器是否在执行您所期望的操作，以便向您提供有关对象的统计信息问题的线索。

from子句中指定的表的实际顺序对性能没有影响。我要说的是，你的同龄人在考虑问题，试图在没有事实的情况下进行优化。只需根据需要编写查询即可获得所需的结果。查看前两个查询的两个版本的解释计划或TKProf文件，CBO将解析语句，并且很可能具有相同的执行计划。添加谓词将再次更改执行计划，因为它现在是一个不同的查询。答案很好！你说的很对，那时候同事在你身边。前两个版本的解释计划完全相同，但第三个版本的解释计划有所不同（成本略低）