Oracle 9与Oracle 8中CPU_COSTING有什么变化？
Oracle 9与之前的Oracle 7和8中CPU_COSTING有什么变化？
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代价，但在多数情况下不会察觉性能的差异。）
总之——这肯定是一个好事。事实上，你可以发现对索引访问路径更强的偏好，这将影响性能。
