Oracle 9 引入了一套更精细和全面的代价机制。这是对Oracle 7/8版的重大改进，但我认为这一改变类似从基于规则转变至基于代价。如果你不理解它是如何运作的，你会看到奇怪的事件。

你可以用dbms_stats包收集一段适当的时间内的系统统计，以此来激活CPU_COSTING。

假定的CPU速度（MHz）

单块读时间（ms）

多块读时间（ms）

一般达到的多块读

这些数字可产生三个主要效用：

Oracle并不假定单块读与多块读一样昂贵，它知道相对速度。这大致与根据数据库文件xxxx读取的平均等待时间设置参数optimizer_index_cost_adj相同——由于Oracle现在认为表扫描比原先理解更昂贵，这将鼓励Oracle使用索引访问路径而不是表扫描。

其次，Oracle将使用“达到的”（achieved）平均多块读取数来计算扫描一张表所需的读请求数，而不是使用一个db_file_multiblock_read_count的调整值。由于很多人使用的db_file_multiblock_read_count值并不合适，这样就造成Oracle可能增加表扫描（和索引快速全扫描）的代价，并由此减少表扫描（和索引快速全扫描）的可能性。

  注意——记录的值是用于计算的，当真正进行扫描时，Oracle会尝试使用init。ora中的值。

最后，Oracle知道（例如）to_char(日期列)=字符值的CPU代价比数字列=数值要打，所以Oracle可能修改索引的选择，若使用一个有更小选择性的索引的连续读代价（consequential cost）低于CPU的使用代价，则会选择这一索引。

  （另外，Oracle将重新安排非访问（non-access）的谓词顺序来减小CPU代价，但在多数情况下不会察觉性能的差异。）

总之——这肯定是一个好事。事实上，你可以发现对索引访问路径更强的偏好，这将影响性能。