在 Oracle 中构建和调整查询时，速度通常是开发人员主要关心的问题。但是，在调整特定查询时，我最近尝试了 FIRST_ROWS 和 NO_CPU_COSTING 提示，生成的执行计划在执行时间上比之前的计划快 80%，但成本高出 300%。执行计划中的 I/O 非常少，而且所有额外开销似乎都来自两个视图之间的嵌套循环外连接。
这个查询是分页的，所以我只需要前几百行。缺乏重要的 I/O 使我认为这个查询不会依赖于缓存，乍一看似乎是要走的路。但是，由于我从未见过查询同时提高速度和成本，因此我不确定使用此查询的缺点可能是什么。有吗？
这是一个非常典型的查询，当需要完整的数据集时，使用 equijoin 优化以使用哈希连接，当只需要前几行时使用嵌套循环，或者排序用于 order by索引可以更有效地用于子集的完整日期集。
当然，如果优化器不知道您将只使用行的子集，那么它不会给出您将实际执行的查询的成本，因为它包括所有嵌套循环操作的成本，这些操作永远不会要去执行。
但是，估计成本并没有错，它就是这样。如果您想要一个更有意义的数字以供您自己理解，请使用 rownum 限制。
顺便说一句，FIRST_ROWS 已被弃用，取而代之的是 first_rows(1)、first_rows(10)、first_rows(100) 或 first_rows(1000)。