如前所述，CBO 使用 CPU 成本模型使用的公式基本上是：
（单个块 I/O 的所有单块 I/O 的平均等待时间之和 x
多块 I/O 的所有多块 I/O 的平均等待时间之和 +
所有所需 CPU 周期的总和/ 每秒的 CPU 周期）
/
单个块 I/O 的平均等待时间
在确定与 FTS 相关的多块 I/O 成本时，CBO 基本上是：
- 确定多块操作的数量（dba_tables /mbrc 系统统计信息中的块数）
- 然后乘以多块 I/O（mreadtim 系统统计信息）
的平均等待时间，以确定所有预期多块读取操作的总等待时间。
-然后，所有多块读取操作的总等待时间最终除以单个块I / O的平均等待时间（sreadtim系统统计量），以表示以单块I / O为单位的最终成本。
请记住，与单块和多块 I/O 关联的这些平均等待时间是这些事件的实际等待时间，这些事件在特定数据库环境中经历并在收集系统统计信息期间捕获。
因此，该公式会自动考虑并将单块和多块I / O
之间等待时间的任何差异和差异纳入计算中，例如，如果多块I / O实际上平均需要（例如）10ms才能执行，而单个块I / O平均只需要（例如）5ms， 然后，该公式将自动使执行多块读取的成本成为执行索引扫描所执行的单个块读取的相关成本的两倍。
在比较与 FTS 相关的多块 I/O 成本与与索引扫描相关的单块 I/O 成本时，这些成本的差异和试图创造一个公平的竞争环境，正是optimizer_index_cost_adj参数旨在解决的问题。
optimizer_index_cost_adj 参数不是将两种类型的 I/O 视为相同（这是 I/O 成本计算模型的默认行为），而是旨在调整单个块读取成本，以确保它们的成本确实是典型多块 I/O 成本的 1/2。
但是，在使用 CPU 成本计算模型时，optimizer_index_cost adj 参数实际上是多余的，因为必要的调整已合并到最终成本中。执行多块读取操作所需的总时间除以执行单个块读取操作所需的平均时间。使用optimizer_index_cost_adj参数（尽管受支持且允许）可能会导致最终 CBO 成本被不恰当地调整，因为与索引相关的单块 I/O 将“双底”，并可能减少由于 sreadtim 和 mreadtim 之间的系统统计差异以及optimizer_index_cost_adj参数的结果。
系统统计信息是首选，只要它们准确并保持合理最新，因为不需要“手动”更改任何关联的数据库参数。
不仅保持了慢导数和反导数之间的比较差异，而且保持了其他有用的系统统计信息，例如接下来要讨论的mbrc 统计信息。
因此，总而言之，在使用 CPU 成本模型时，根本不要设置optimizer_index_cost_adj参数。别管它，收集代表性的系统统计信息，并让系统统计信息自动为您处理单块和多块I / O之间的比较成本。
参考至:http://richardfoote.wordpress.com/2009/12/14/the-cpu-costing-model-a-few-thoughts-part-ii/
如有错误，欢迎指正
