问题标签 [optimizer-hints]

我有一个函数，它使用一些 xmlaggs 数据调用几个表/视图等。

出于某种原因，当我提取附加信息时，我得到了性能提升，即使这些额外信息没有用于其余代码（例如再次使用的键值的索引）。

我已经在快速和慢速查询上运行了 tkprof，我看到了一些问题 - 第一个是慢速查询在解析和执行期间有遗漏，而快速查询没有。

我的主要问题是，再往下看，我可以看到我的一个视图的成本很高 - 更快的查询使用基础表上的 3 个索引，而慢速查询没有使用任何索引。

我试图插入一个提示：

但是它仍在进行全表扫描。我是否将优化器提示放在错误的位置或为此使用了错误的语法？

编辑-我一直在做更多的调查，看来这可能是Oracle进行哈希联接而不是嵌套循环的敲门声，但是我的选择来自多个表-我可以在所有3个表上强制使用USE_NL吗？我怎么知道 pl/sql 的哪个区域导致了这种情况，因为它被多次调用。

28/08 更新 - 添加了赏金。让我知道是否有任何额外的要求。

更新 01/09 -

有两个注释掉的选择，当任何一个未注释时，它们都会成为执行速度更快的查询。t1 和 t2 根本不在查询中的其他地方使用。

更新 01/09 以下是执行计划：快速http://pastebin.com/pbJMSxrB 慢速http://pastebin.com/zt3eUYNd

这是我希望纠正的第 86 行中的高成本。这可能是此处完整扫描的结果，或者是进一步向上连接的结果。

我试图强制 oracle 数据库 11g 快速版在两个 JOIN SELECT 中使用两种特定方法进行 JOIN，但是当我尝试使用 USE_MERGE 和 USE_NL 提示时它不起作用。我的 SELECT 看起来像这样：

但我得到的实际解释计划是这个：

解释我从 oracle 获得的计划

我对此感到非常绝望，并且一直在查看出色的 oracle 文档，但仍然无法实现。这个例子看起来很相似，但我不知道为什么不使用我正在尝试的组合。下一个代码是 Oracle 提供的示例：

提前感谢您的帮助：D

我正在使用 Oracle 11g。我有一个使用数据库链接将本地表与远程表连接起来的查询。我希望驱动表成为远程表，因为我主要使用远程表进行过滤以获取几行。然后我想加入他们与本地表。

问题是优化器忽略了 ORDERED 和 INDEX 提示，并对本地表进行全表扫描。我正在使用正确的索引并生成了统计信息。我对使用正确索引的每个表单独运行查询，但是通过连接，本地表始终执行全表扫描并充当驱动表。

我有一条存在性能问题的 SQL 语句。

添加以下索引和使用该索引的 SQL 提示可将性能提高 10 倍，但我不明白为什么。BUS_ID 是主键的一部分（T1.REF 是键的另一部分）和 T1 表上的聚集索引。

T1 表有大约 100,000 行。BUS_ID 只有 6 个不同的值。同样，T1.STATUS 列只能有有限数量的可能性，其中大多数（99%）将是相同的值。

如果我在没有提示的情况下运行查询(/*+ INDEX (T1 T1_IDX1) NO_UNNEST */)，则需要 5 秒，而有提示则需要 0.5 秒。我不明白索引如何帮助子查询，因为子查询中的任何“where”或“join”子句中都没有使用 T1.STATUS。

我错过了什么？

编辑包括解释计划和索引。

带索引提示

表索引

我们在一个大约有 50 列的表中有大约 800 万条记录，我们需要非常快速地查看少量记录，因此我们为此目的使用 FIRST_ROWS(10) 提示，并且它的工作速度非常快。

但是，当我们放置 ORDER BY 子句时，例如创建时间（这几乎是该表中每一行的唯一值），此查询将需要很长时间才能返回所有列。

我注意到的一件事是；如果我们为某个列（例如 VERSION）放置一个 ORDER BY，它对多行具有相同的值，它会提供更好的结果。

对于此表中的列这样的任何唯一列，这ORDER BY都不能有效地工作ID。

另一件值得考虑的事情是；如果我们减少要获取的列数，例如 3 列而不是 50 列，结果会以某种方式更快地出现。

PS 收集统计信息每周在此表上运行，但数据每小时推送一次。只有INSERT语句在此表上运行，没有DELETE或UPDATE查询在此表上运行。

此外，还有一个没有创建此表的简单视图，上述查询正在同一视图上运行。

我们有一些存储时态数据的表，这些表具有由 3 列组成的自然主键。示例：当天的最高温度。这是复合主键索引（按此顺序）：

简化逻辑：当我们在上午 10:00 进行预测时，为这个 id/day 组合找到的最后一个条目的 create_at 更改为上午 9:59，并且新计算的值与 kill_at 时间戳“31.12.2999”一起存储。

此表上的典型查询是：

有很多我们无法预测的时间序列。这意味着当它被衡量时，我们会得到一个有价值的东西，而且它永远不会改变。但是有些时间序列我们预测 200-300 次。因此，对于一个 id/day 组合，有 200 多个具有不同 kill_at 值的条目。

我们目前只有主键（id、day、kill_at）作为该表的唯一（唯一）索引。但是当我使用查询 2（确切的 id 和日期范围）进行查询时，优化器决定只使用索引的第一列。

对于那些更新了 200 多次的时间序列，这真的很伤我们。现在我正在寻找一种方法来强制优化器使用我们索引的所有 3 列，但我找不到任何提示。有吗？

或者关于如何加快我的查询还有其他建议吗？我们试图减少高峰持续时间。平均持续时间不太重要。

让我感到困惑的是：上面的执行计划是我在 dba_hist_sql_plan 中看到的。这是该语句的唯一执行计划。但是当我让我的客户展示解释计划时，搜索列有时是 1 或 3。但当我们的应用程序运行此语句时，它永远不会是 3。

我不熟悉在 oracle 中使用提示优化器的概念，我想了解我是否正确使用提示 FULL

我有一个查询

所以假设结果让我得到了 12345

现在，如果我想使用 FULL 提示，它应该这样写在下面吗？

结果也是12345正常吗？

谢谢

考虑如下查询：

假设 Oracle 执行条件（任何条件），如果不为真，则不执行其他条件。因此，如果我有其他具有逻辑错误的条件，则不会抛出它。例如：

Oracle 返回 0。现在去掉 1=0 条件，我们得到ORA-01722: invalid number.

我知道 Oracle 会进行成本优化并决定条件执行的顺序。那么如何覆盖它并使其执行所有条件，以便引发错误而不是误导性输出？我们可以使用提示吗？我是提示概念的新手，所以一些例子会很棒。

我浏览了网上的一些文档，并且大多不鼓励使用提示。我对此仍有疑问。当数百个不同的客户使用相同的查询时，提示在生产中是否真的有用。

只有当我们知道表中存在的记录数时，提示才有用吗？我在查询中使用前导，当数据非常大时它会提供更快的结果，但是当获取的记录较少时性能不是那么好。

大卫的这个答案非常好，但如果有人更详细地澄清这一点，我将不胜感激。

我SELECT /*+USE_CONCAT*/在我的查询中添加了一个。我在 SQL Developer 中发现了很大的差异（仅前 200 行），但我不能说我在 SSIS 中发现了同样的改进。也许那是因为返回的记录数量巨大，但我也有一个可疑的/*+USE_CONCAT*/被认为是评论。有人知道更多吗？提前致谢。