所以，几个星期前，我询问了有关FIRST_ROWS（n）提示的Oracle execution plan cost vs speed 。我遇到了类似的问题，但这次是关于ORDERED的提示。当我使用提示时，我的执行时间显着提高（超过90％），但查询的EXPLAIN PLAN报告了巨大的成本增加。在此特定查询中，成本从1500到24000.
查询的参数为paramination，并连接19个表以获取数据。我在这里发布它，但是它长达585行，是为供应商杂乱，神秘的架构而编写的。除非你碰巧熟悉这个用过的产品，否则看起来并没有多大帮助。但是，在开始调优查询的工作之前不久，我收集了100％的模式统计信息，因此CBO在这里没有工作。
我将尝试总结查询的作用。查询本质上返回系统中的对象及其子节点，并且构造为直接连接到多个表的大子查询块。第一部分返回对象ID，并在连接到其他表之前在其查询块内进行分页。然后，它连接到包含子ID的多个表。
我知道CBO并不是全部都知道或不可靠，但我真的很难看到这个代价高昂的执行计划表现得如此之好;它违背了我所教过的很多东西。使用FIRST_ROWS提示，解决方案是提供值n，以便优化器可以可靠地生成执行计划。对于我的查询，ORDERED提示是否发生了类似的事情？
答案 0 :(得分：2)
您不应该依赖执行成本来优化查询。重要的是执行时间（在某些情况下是资源使用）。
费用是估算值，与使用特定计划执行语句所需的预期资源使用成比例。
当估算结束时，通常是因为优化程序可用的统计数据具有误导性。您可以通过为优化程序提供更准确的统计信息来纠正错误。检查统计信息是否是最新的。如果是，您可以收集其他统计信息，例如通过启用动态统计信息收集，在数据偏斜列上手动创建直方图。
可以解释相对成本和执行时间之间差异的另一个因素是优化器基于简单的假设。例如：
这些假设是为了使优化器可以返回单个数字（而不是间隔）的执行成本。对于大多数查询，这些近似值并不重要，结果也足够好。
但是，您可能会发现有时情况对于优化程序而言过于复杂，甚至收集额外的统计信息也无济于事。在这种情况下，您必须手动优化查询，方法是自己添加提示，重写查询或使用Oracle工具（例如SQL profiles）。
如果Oracle可以设计出准确确定执行成本的方法，我们就不需要首先手动优化查询！
答案 1 :(得分：2)
报告的成本用于执行完整查询，而不仅仅是第一组行。 （PostgreSQL的成本略有不同，因为它提供了初始返回行和整个集合的成本。）
对于某些计划，大部分成本是在返回第一行之前产生的（例如，使用排序合并的地方），而对于其他计划，初始成本非常低，但此后每行的成本相对较高（例如。嵌套循环连接）。
因此，如果您正在优化前几行的返回并加入19个表，那么使用嵌套的基于循环的计划返回前20个可能会获得非常低的成本。但是，对于完整的行集，该计划的成本可能远远高于其他针对返回所有行而优化的成本，但会以返回第一行的延迟为代价。