何时在oracle查询中使用提示

Question

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

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

大卫的这个answer非常好，但如果有人更详细地说明这一点，我将不胜感激。

Answer 1

大多数提示是将我们的意图传达给优化器的一种方式。例如，您提到的leading提示意味着按此顺序连接表。为什么这有必要？通常它是因为最佳连接顺序不明显，因为查询编写错误或数据库统计信息不准确。

因此，使用诸如leading之类的提示是为了找出最佳执行路径，然后找出数据库没有提示而没有选择该计划的原因。收集新的统计数据能解决问题吗？重写FROM子句是否解决了这个问题？如果是这样，我们可以删除提示并部署裸SQL。

有时我们无法解决这个难题，必须保留生产中的提示。然而，这应该是一个罕见的例外。多年来，Oracle已经有很多非常聪明的人在使用基于成本的优化器，因此它的决策通常比我们的更好。

但是还有其他一些提示，我们不会在制作中看到它们。 append通常对调整批量插入至关重要。 driving_site对于调优分布式查询至关重要。

相反，其他提示几乎总是被滥用。是parallel，我正在谈论你。盲目地放置/*+ parallel (t23, 16) */可能不会使查询运行速度提高十六倍，而且不经常会导致慢检索而不是单线程执行。

因此，简而言之，我们何时应该使用提示，没有普遍适用的建议。关键是：

1. 了解数据库的工作原理，尤其是基于成本的优化器的工作原理;
2. 了解每个提示的作用;
3. 使用与生产等效的数据在适当的调整环境中测试提示查询。

显然，最好的起点是the Oracle documentation。但是，如果你想花一些钱，Jonathan Lewis关于the Cost-Based Optimizer的书是你可以做的最好的投资。

Answer 2

我无法改写，所以我会把它贴在这里 （它是＆＃34;何时不使用提示＆＃34; ，我已经加入书签的简短解释）：

总之，不要在

时使用提示

1. 提示的作用很难理解，当然不限于（ab）使用提示;

2. 您尚未查看错误SQL代码的根本原因，因此尚未利用DBA调整数据库的丰富专业知识和经验;

3. 您的统计信息已过期，您可以更频繁地刷新统计信息，甚至可以将统计信息修复为代表状态;

4. 您不打算定期检查报表中提示的正确性，这意味着，当统计数据发生变化时，提示可能会严重不足;

5. 无论如何，您无意记录提示的使用。

来源链接here。

我可以将其概括为：使用提示不仅是最后的手段，而且还缺乏对问题根本原因的了解。如果您只是确保一些基础知识，CBO（基于成本的优化工具）的工作非常出色。其中包括：

1. 新鲜统计数据 1.1。指数统计 1.2。表统计 1.3。直方图
2. 更正JOIN条件和INDEX利用率
3. 更正数据库设置

这篇文章值得一读： Top 10 Reasons for poor Oracle performance

由其他人提出，但Donald Burleson先生。

干杯

Answer 3

一般情况下，提示应仅用于例外情况，我知道以下情况：

Oracle漏洞的解决方法

示例：对于SELECT语句，我收到错误ORA-01795: maximum expression number in list - 1000，尽管查询根本不包含IN表达式。

问题是：查询的表包含超过1000个（子）分区，Oracle对我的查询进行了转换。使用（未记录的）提示NO_EXPAND_TABLE解决了这个问题。

登台时的Datewarehouse应用程序

在暂存时，您可以对数据进行重大更改，而表/索引统计信息并不知道，因为默认情况下每周只会收集一次统计信息。如果你知道你的数据结构，那么提示可能很有用，因为它们比在你的操作之间一直手动运行DBMS_STATS.GATHER_TABLE_STATS(...)更快。另一方面，即使对于可能是更好方法的单列，您也可以运行DBMS_STATS.GATHER_TABLE_STATS()。

在线申请升级提示

来自Oracle documentation：

  

CHANGE_DUPKEY_ERROR_INDEX，IGNORE_ROW_ON_DUPKEY_INDEX和   RETRY_ON_ROW_CHANGE提示不同于其他提示，因为他们有一个   语义效应。一般哲学在＆＃34; Hints＆＃34;才不是   申请这三个提示。