【部分转载】http://www.xifenfei.com/2012/06/optimizer_index_caching和optimizer_index_cost_adj参数说明.html
1、
OPTIMIZER_INDEX_COST_ADJ 参数说明
OPTIMIZER_INDEX_COST_ADJ lets you tune optimizer behavior for access path selection to be more or less index friendly—that is, to make the optimizer more or less prone to selecting an index access path over a full table scan.
The default for this parameter is 100 percent, at which the optimizer evaluates（评估） index access paths at the regular cost. Any other value makes the optimizer evaluate the access path at that percentage of the regular cost. For example, a setting of 50 makes the index access path look half as expensive as normal.
这个数反映执行多块IO（全表扫描）的成本与执行单个IO（索引读取）的成本。保持为100，则多块IO与单块IO成本相同。设为50优化程序认为访问单块IO的成本为多块IO的一半。
优化器计算通过索引扫描访问表数据的cost开销，可以通过这个参数进行调整。参数可用值的范围为1到10000。默认值为100，超过100后越大则越会使索引扫描的COST开销越高（计算的），从而导致查询优化器更加倾向于使用全表扫描。相反，值越小于100，计算出来的索引扫描的开销就越低。
OPTIMIZER_INDEX_COST_ADJ参数试验
SQL> create table t_xifenfei
2 as
3 select object_id,object_name from dba_objects where rownum<101;
Table created.
SQL> create index ind_t_xifenfei on t_xifenfei(object_id);
Index created.
SQL> EXEC DBMS_STATS.gather_table_stats(user,'T_XIFENFEI',CASCADE=>TRUE);
PL/SQL procedure successfully completed.
SQL> show parameter OPTIMIZER_INDEX;NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
SQL> set linesize 150
SQL> set autot trace ext
SQL> select object_name from t_xifenfei where object_id>100;
Execution Plan----------------------------------------------------------Plan hash value: 2444553208----------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 11 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 11 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_T_XIFENFEI | 1 | | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------- 2 - access("OBJECT_ID">100)
SQL> alter session set OPTIMIZER_INDEX_COST_ADJ=1000;
Session altered.SQL> select object_name from t_xifenfei where object_id>100;
Execution Plan----------------------------------------------------------Plan hash value: 548923532--------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T_XIFENFEI | 1 | 11 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------- 1 - filter("OBJECT_ID">100)
|
通过试验证明修改OPTIMIZER_INDEX_COST_ADJ会导致执行计划走index还是全表扫描
2、
OPTIMIZER_INDEX_CACHING参数说明
OPTIMIZER_INDEX_CACHING lets you adjust the behavior of cost-based optimization to favor nested loops joins and IN-list iterators.The cost of executing an index using an IN-list iterator or of executing a nested loops join when an index is used to access the inner table depends on the caching of that index in the buffer cache. The amount of caching depends on factors that the optimizer cannot predict, such as the load on the system and the block access patterns of different users.You can modify the optimizer’s assumptions about index caching for nested loops joins and IN-list iterators by setting this parameter to a value between 0 and 100 to indicate the percentage of the index blocks the optimizer should assume are in the cache. Setting this parameter to a higher value makes nested loops joins and IN-list iterators look less expensive to the optimizer. As a result, it will be more likely to pick nested loops joins over hash or sort-merge joins and to pick indexes using IN-list iterators over other indexes or full table scans. The default for this parameter is 0, which results in default optimizer behavior.
这个表明的是在nested loops joins and IN-list iterators的时候,如果使用了OPTIMIZER_INDEX_CACHING参数,表明两个表关联的时候优化器考虑index cache的比例,从而选择不同的执行计划.而不是网上所说的优化器考虑所有情况下的index的cache情况(这个参数只有在nested loops joins and IN-list iterators表关联的时候的index才会被优化器考虑[index cache的比例]).进一步说明:这个参数影响两个表关联的时候是选择hash jion还是nested loops joins/sort-merge joins。
如下是tomkyte书中的描述：
可以使用 OPTIMIZER_INDEX_CACHING参数告诉oracle能够在缓冲区高速缓存中找到的索引块的平均百分比，0默认值使oracle 认为高速缓存中没有索引块。最大值100使oracle认为高速缓存中具有所有索引块。所要使用的值很难精确指定，但它一定是0到100之间的某个值。你可能希望用接近于高速缓存命中率的某个值作为开始，然后不断调整看其对系统的作用如何。
对于许多系统，应该考虑设置这两个参数为非默认值，或者至少测试一下两种极端情形：
OPTIMIZER_INDEX_CACHING = 0 和 OPTIMIZER_INDEX_COST_ADJ = 100 的默认设置。它们一般适合与许多数据仓库/报表系统。
OPTIMIZER_INDEX_CACHING = 90 和 OPTIMIZER_INDEX_COST_ADJ = 25 的设置。它们一般适合于许多事物处理/OLTP系统。