因此，几周前，我询问了 Oracle 执行计划成本与速度 与 FIRST_ROWS(n) 提示的关系。我遇到了类似的问题，但这次是围绕 ORDERED 提示。当我使用提示时，我的执行时间显着提高（高达 90%），但查询的 EXPLAIN PLAN 报告了巨大的成本增加。在这个特定的查询中，成本从 1500 到 24000。
查询参数化为分页，并连接 19 个表以获取数据。我本来想把它贴在这里，但它有 585 行长，而且是为供应商混乱、糟糕的模式编写的。除非您碰巧非常熟悉它所使用的产品，否则看到它并没有多大帮助。然而，在开始调整查询之前不久，我收集了 100% 的架构统计信息，因此 CBO 并不是在黑暗中工作。
我将尝试总结查询的作用。该查询本质上返回系统中的对象及其子对象，并且其结构为直接连接到多个表的大型子查询块。第一部分返回对象 ID，并在连接到其他表之前在其查询块内分页。然后，它连接到多个包含子 ID 的表。
我知道 CBO 并不全知或不会犯错，但看到如此昂贵的执行计划执行得如此之好，我真的很困扰；这违背了我所学到的很多东西。通过 FIRST_ROWS 提示，解决方案是提供一个值 n，以便优化器可以可靠地生成执行计划。我的查询的 ORDERED 提示是否发生类似的情况？
报告的成本是执行完整查询的成本，而不仅仅是第一组行的成本。 （PostgreSQL 的成本计算略有不同，因为它提供了行的初始返回和完整集的成本）。
对于某些计划，大部分成本是在返回第一行之前产生的（例如，使用排序合并的情况），而对于其他计划，初始成本非常低，但此后每行的成本相对较高（例如，嵌套）循环连接）。
因此，如果您正在优化前几行的返回并连接 19 个表，则使用基于嵌套循环的计划返回前 20 行的成本可能非常低。然而，对于完整的行集，该计划的成本可能比其他针对返回所有行进行优化但以延迟返回第一行为代价的计划要高得多。
您不应依赖执行成本来优化查询。重要的是执行时间（在某些情况下还有资源使用情况）。
摘自概念指南：
成本是一个估计值，与执行具有特定计划的语句所需的预期资源使用量成正比。
当估计出现偏差时，最常见的原因是优化器可用的统计数据具有误导性。您可以通过为优化器提供更准确的统计信息来纠正该问题。检查统计数据是否是最新的。如果是，您可以收集其他统计信息，例如通过启用在数据倾斜列上手动创建直方图的动态统计信息收集。
可以解释相对成本和执行时间之间差异的另一个因素是优化器是建立在简单的假设之上的。例如：
做出这些假设是为了让优化器可以返回单个数字（而不是区间）的执行成本。对于大多数查询来说，这些近似值并不重要，结果已经足够好了。
但是，您可能会发现有时情况对于优化器来说过于复杂，甚至收集额外的统计信息也无济于事。在这种情况下，您必须手动优化查询，方法是自己添加提示、重写查询或使用 Oracle 工具（例如SQL 配置文件）。
如果 Oracle 能够设计出一种方法来准确确定执行成本，那么我们一开始就不需要手动优化查询！
我遇到了同样的问题。 90%的时间都用来生成完美的优化执行计划。如果我添加 ORDERED 提示，则该计划不是最佳的。但总的执行时间（计划+实际执行）比当时完美的计划要快得多。