在接下来的几天里，我将发布一系列小条目，重点介绍与系统统计信息的使用和 CPU 成本模型相关的特定点。在我之前的文章中，我们研究了如何使用 CPU 成本模型计算 FTS 的成本，以及这通常如何导致相关 FTS 成本相对于 I/O 成本模型的增加。
在我的演示中，该表虽然有一个具有骇人听闻的聚类因子的指数，尽管FTS的成本从33大幅增加到70，但这个成本仍然大大低于使用这种低效指数的相关巨大成本。因此，在该特定示例中，CPU 成本计算模型引入的 FTS 成本变化对最终执行计划没有影响。
我想在这篇文章中强调的关键点是，通过增加FTS成本，就像CPU成本模型而不是I / O成本模型一样，这当然可能会导致完全不同的执行计划，特别是如果候选指数具有合理的聚类因子。大幅增加FTS的相关成本可能非常重要，特别是对于聚集良好的指数，FTS和指数之间的成本差异可能要小得多。
在前面的 I/O 成本计算模型示例中使用BOWIE_STUFF2表，索引具有出色的聚类因子。然而，查询结果为 FTS，因为 65 的成本仅略低于使用关联索引的成本：
SQL>从 id 中bowie_stuff2中选择 *（20、30、40、50、60）;
已选择 10000 行。
执行计划
———————————————————-
计划哈希值：573616353
——————————————————————
|编号 |操作|名称|行|字节|成本|
——————————————————————
|0 |选择对账单| |10000 |17.5万|65 |
|*1|表访问完全|BOWIE_STUFF2 |10000 |17.5万|65 |
——————————————————————
请记住，这是“解决”的，CBO 开始使用索引，方法是手动将 optimizer_index_cost_adj 参数从其默认值调整为 75，如上一篇关于optimizer_index_cost_adj参数的影响的文章中所述。
但是，使用系统统计信息和 CPU 成本模型，额外的 FTS 成本可能会对生成的执行计划产生直接影响。再次运行相同的查询，但这次没有更改任何优化器参数，并且使用与我上一篇关于 CPU 成本模型的文章中相同的系统统计信息：
PNAME PVAL1 -------- ----- SREADTIIM 5 MREADTIIM 10 CPUSPEED 1745 MBRC 10
SQL>从 id 中bowie_stuff2中选择 *（20、30、40、50、60）;
已选择 10000 行。
执行计划
———————————————————-
计划哈希值：2964430066
———————————————————————————————–
|编号 |操作|名称|行|字节|成本 （%CPU）|时间|
———————————————————————————————–
|0 |选择对账单| |10000 |17.5万|69（2）|00：00：01 |
|1 |列表迭代器| | | | | |
|2 |按索引 ROWID 进行表访问|BOWIE_STUFF2 |10000 |17.5万|69（2）|00：00：01 |
|*3|索引范围扫描|BOWIE_STUFF2_I |10000 | |25（0）|00：00：01 |
———————————————————————————————–
我们注意到 CBO 现在自动选择了索引，而无需对optimizer_index_cost_adj参数进行任何更改。
此前，FTS成本为65。但是，FTS的当前成本至少是：
（ceil（块/mbrc）x mreadtime）/sreadtime = （ceil（659/10） x 10） / 5 = 132.
132已经远远大于与使用上述指数相关的69成本，132成本甚至没有考虑与CPU使用率相关的任何额外费用。
因此，一般来说，使用CPU成本模型可能会增加FTS的相关成本，从而使指数自动对CBO更具“吸引力”。仅使用 CPU 成本模型对 FTS 进行成本核算的这种变化本身就会对 CBO 选择的执行计划产生重大影响。这只是为什么从9i移动到10g时事情会发生如此巨大变化的关键原因之一，其中CPU成本模型是默认的。
参考至:http://richardfoote.wordpress.com/2009/12/08/the-cpu-costing-model-a-few-thoughts-part-i/
如有错误，欢迎指正
