Oracle 优化器提示在生产代码中是否明智？

Question

随着我对 Oracle 的了解（过去几十年一直是 DB2 专家），我看到大量现有代码在其查询中使用优化器提示。

根据我在各种以 Oracle 为重点的网站上阅读的内容，一些 Oracle“专家”建议不要将优化器提示放在生产代码中，因为：

• 对于每个 Oracle 补丁或升级，提示可能都是错误的。
• 对于每个 DDL，提示可能都是错误的。

一位“专家”说：

对提示保持警惕的原因是，通过在 SQL 中嵌入提示，您会覆盖优化器并说您知道的比它知道的更多——不仅是现在，而且将来每次运行您的 SQL ，而不管您的数据库可能发生的任何其他更改。这样做的可能后果是，您的 SQL 现在可能会以次优方式运行，并且几乎可以肯定在未来。

（见http://allthingsoracle.com/a-beginners-guide-to-optimizer-hints/）

那么，如果优化器提示通常被认为是“不明智的”，那么为什么它们会如此频繁地使用（……至少在我见过的代码中）？

Answer 1

就提示很常见的程度而言，这通常是因为过去有人优先考虑解决严重问题，而不是处理潜在的统计问题。这种优先排序完全有可能是合理的（尤其是在当时），但它引入了可能必须偿还的技术债务。

当系统因为查询计划发生变化而变得无响应并且效率大大降低时，解决严重的生产问题通常优先于确定根本原因。对单个查询进行提示通常比找出潜在问题或学习如何使用 Oracle 提供的各种工具来确保查询计划的稳定性或随着时间的推移而改进计划更快、更容易。

当然，在单个查询上打了一个创可贴，如果你不花时间去理解为什么统计数据会使优化器走错路，或者为什么你的计划稳定性方法不起作用，那就是无论您遇到什么统计问题，都可能导致其他查询执行不佳。误导性统计数据很少会导致系统中的一个查询性能不佳。通常，这要么导致一个粘性循环，即更多查询开始表现不佳，从而导致添加更多提示，要么是一个良性循环，DBA 后退一步，解决导致查询性能受损的问题，修复潜在问题，以及然后删除提示。

话虽如此，根据您使用的代码类型，有一些提示可能会相对普遍地合理使用。如果您有一个返回 sys_refcursor 的函数，该函数将返回给您知道将获取前几行的客户端应用程序，将它们显示给用户，并且仅在它们不要求时才询问下一组行'找不到他们正在寻找的东西，使用FIRST_ROWS 提示是有意义的，因为你知道优化器不可能知道的东西。您知道用户对前几行而不是完整的结果集更感兴趣。如果您有大量代码在 SQL 中使用集合，您可能希望使用大量 CARDINALITY 提示，否则 Oracle 不知道集合可能包含多少元素。

Answer 2

就我而言，我在生产代码中看到的大部分提示都是这样的：

/*+APPEND*/
/*+ full(MP) parallel(MP, 16) */
/*+ PARALLEL(ME1, 16) FULL(ME1) DRIVING_SITE(ME1) */ 

很少（但每隔一段时间），我会看到一个索引提示：

例如

/*+ index(MSL XCL01000) */ 

感谢您的宝贵意见。我当然更了解提示的危险和必要性。