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