何时Oracle使用绑定变量性能反而更差

Mischievous

UID: 14419
帖子: 54
积分: 124
在线时间: 4 小时

1^# Mischievous 发表于 2007-02-01 00:30

何时Oracle使用绑定变量性能反而更差

　　当我在做培训时，在解释绑定变量的好处时，大家都比较容易理解。但是，对于并不是任何时候绑定变量都是最优的。这一点很多人不是和理解。下面就讨论一下在什么时候会出现绑定变量会使性能变差。

　　扫描成本和OPTIMIZER_INDEX_COST_ADJ

　　我们知道，在CBO模式下，Oracle会计算各个访问路径的代价，采用最小代价的访问路径作为语句的执行计划。而对于索引的访问代价的计算，需要根据一个系统参数OPTIMIZER_INDEX_COST_ADJ来转换为与全表扫描代价等价的一个值。这是什么意思呢？我们先稍微解释一下这个参数：OPTIMIZER_INDEX_COST_ADJ。它的值是一个百分比，默认是100，取值范围是1～10000。当估算索引扫描代价时，会将索引的原始代价值乘以这个百分比，将换算后的值作为与全表扫描代价比较的值。也就是说，当这个值为100时，计算出的索引扫描代价就是它的原始代价：

引用:

COST_COM = COST_ORG * OPTIMIZER_INDEX_COST_ADJ/100

Mischievous

UID: 14419
帖子: 54
积分: 124
在线时间: 4 小时

2^# Mischievous 发表于 2007-02-01 00:31

　　可以看出，在使用绑定变量时，参数OPTIMIZER_INDEX_COST_ADJ对于是否选择索引会有重要的影响。这里我们暂且不讨论索引扫描的原始成本是如何计算得出的。但是有一点很重要，在使用绑定变量时，计算出的成本是平均成本。在我们上面的例子中，字段B的值只有3个："A"、"B"、"C"，其中A最多，1003行中有1000行。因此，在索引上扫描值为A记录的成本为1000/1003 * 索引全扫描成本 ≈索引全扫描成本，我们看下它的成本是多少：

引用:

SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=100;

System altered.

SQL>
SQL> delete from plan_table;

2 rows deleted.

SQL>
SQL> explain plan for select
/*+index(a T_PEEKING_IDX1)*/* from T_PEEKING a where b = 'A';

Explained.

SQL>
SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||
  2       object_name||' '||decode(id, 0, 'Cost='||position) "Query
  3  Plan_Table"
  4    from plan_table
  5    start with id = 0
  6    connect by prior id = parent_id;

Query
Plan_Table
--------------------------------------------------------------
SELECT STATEMENT Cost=336
  TABLE ACCESS BY INDEX ROWID T_PEEKING
INDEX RANGE SCAN T_PEEKING_IDX1

Mischievous

UID: 14419
帖子: 54
积分: 124
在线时间: 4 小时

3^# Mischievous 发表于 2007-02-01 00:32

　　用Tkprof处理生成的trace文件。因为在存在绑定变量窥视时，autotrace或者explain plan可能不会显示正确的查询计划，需要Tkprof来处理sql trace。

引用:

tkprof fuyuncat_ora_5352.trc aaa.txt