gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-03 22:23:35 25 4
gpt4 key购买 nike

随着我对 Oracle 的快速了解(过去几十年一直是 DB2 专家),我看到很多现有代码在其查询中使用优化器提示。

根据我在各种以 Oracle 为中心的网站上的阅读,几位 Oracle“专家”建议反对将优化器提示放在生产代码中,因为:

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

  • 一位“专家”说:

    The reason to be wary of hinting is that by embedding hints in your SQL, you are overriding the optimizer and saying that you know more than it does – not just now, but every time in the future that your SQL will be run, irrespective of any other changes that may happen to your database. The likely consequence of this is that your SQL will possibly run sub-optimally now and almost certainly in the future.



    (见 http://allthingsoracle.com/a-beginners-guide-to-optimizer-hints/)

    所以,如果优化器提示通常被认为是“不明智的”,为什么它们如此频繁地使用(......至少在我见过的代码中)?

    最佳答案

    在某种程度上,提示很常见,这通常是因为过去有人优先解决一个严重的问题,而不是处理潜在的统计问题。这种优先级排序完全有可能是合理的(特别是在当时),但它引入了可能必须偿还的技术债务。

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

    当然,在对单个查询贴上创可贴之后,如果您不那么投入时间来了解为什么统计数据将优化器发送到错误的路径上,或者为什么您的计划稳定性方法不起作用,那么很可能无论您遇到的统计问题将导致其他查询性能不佳。误导性统计数据会导致系统中的一个查询表现不佳的情况非常罕见。通常,这要么导致一个粘性循环,其中更多的查询开始表现不佳导致添加更多提示,或者导致一个良性循环,其中 DBA 退后一步,解决导致查询性能下降的问题,修复潜在问题,以及然后删除提示。

    话虽如此,根据您使用的代码类型,有一些提示可能会相对普遍地合理使用。如果你有一个返回 sys_refcursor 的函数返回到客户端应用程序,您知道它将获取前几行,将它们显示给用户,并且如果他们没有找到他们正在寻找的内容,则仅询问下一组行,这是有道理的使用 FIRST_ROWS非常自由地暗示,因为您知道优化器不可能知道的事情。您知道用户对前几行而不是完整的结果集更感兴趣。如果你有很多在 SQL 中使用集合的代码,你可能想使用很多 CARDINALITY提示,否则 Oracle 不知道该集合可能包含多少个元素。

    关于oracle - Oracle 优化器提示在生产代码中是否明智?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28816385/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com