关于CBO CPU成本模型和系统统计数据，我还有很多话要说，但我现在要对这个主题做最后一点评论。
如前所述，CPU 成本模型基本上需要执行所有必要的 I/O 相关活动所需的时间，以及执行所有必需的 CPU 相关活动所需的所有时间，并将它们相加以获得完成任务的总时间。然后，CBO 将此总数除以执行单个块 I/O 的平均时间，以便以单个块 I/O 为单位表示总成本。
以这种方式表达CBO成本有两个优点。
首先，它使从旧的I / O成本计算模型的转变变得更加容易，因为两个CBO成本计算模型下的成本“单位”非常相似。
使用I/O成本计算模型，成本单位基本上也是I/O的数量。只是 CBO 没有（自动）区分与单块和多块读取相关的 I/O 成本。成本只是给定执行计划的预期 I/O 总数，单块和多块 I/O 被视为相同（除非optimiser_index_cost_adj参数启动）。
通过 CPU 成本核算建模，成本以单块 I/O 为单位专门表示。但是，CBO 会自动考虑并区分与多块 I/O（和 CPU 操作）相关的相对成本，并自动将其合并到最终成本中。
另一个不错的优点是，可以使用实际成本值来指示操作或执行计划可能需要多长时间。使用 CPU 成本计算公式时，计划的总体执行时间除以单个块 I/O 的平均时间。因此，通过再次将这些成本值乘以单个块 I/O 的平均时间（SREADTIM 系统统计量），可以对总体预期执行时间有一个指示性的概念。
因此，CBO 使用 CPU 成本模型估计的总执行时间基本上是 = 执行计划的成本乘以 SREADTIM 系统统计数据。
使用我之前的示例，其中执行计划的总成本为 70，SREADTIM 系统统计数据为 5：
CBO 估计的总执行时间约为 70 x 5 = 350 毫秒
。由于所有与系统相关的统计信息都只是平均值，因此特定I/O实际执行所需的时间，特定多块读取操作的大小和数量等明显存在差异。对象也可能存在缓存特征，这些特征可能会影响物理读取的实际次数和相关的等待时间，它没有考虑实际将数据返回到“客户端”所需的时间，等等等等
。如果上述示例中的实际执行时间是（例如）20 秒，则强烈表明 CBO 可能搞错了，它可能计算了错误的成本，结果可能是错误的执行计划。在某个地方，诸如段统计信息、系统统计信息、优化器参数等内容可能不准确，并导致 CBO 的成本不正确。
CBO的成本价值与现实相比并不好，因此可能值得进一步研究。
与 CPU 成本计算模型关联的成本值不是某个随机的、模棱两可的、神秘的数字，而是一个通常可以派生的值，并且在确定和解决有问题的 SQL 语句和执行计划时最有用。
参考至：http://richardfoote.wordpress.com/2010/01/13/the-cpu-costing-model-a-few-thoughts-part-v-reality/
如有错误，欢迎指正
