索引 的聚簇因子对能否用到该索引的影响的实验
2015-04-03 14:00
239 查看
在理论学习中，我们了解到，索引的聚簇因子（clustering_factor)对CBO是否选择使用索引有很大的影响。所以，首先通过以下模拟实验来加深印象：
创建测试表t0403a,共两列（ID列和COL1列），其中ID列为一个1000以内的随机数。然后在ID列上创建索引。这样做的目的就是想让该索引的聚簇因子较大。因为用这种方式创建的表中数据存放顺序与ID的大小是完全不相关的，即是混乱的，不是有序的。
SQL> create table t0403a as select ceil(dbms_random.value*1000) id,rpad(rownum,50,'a') col1 from dual connect by rownum<=1000;
Table created.
SQL> create index ind_t0403a on t0403a(id);
Index created.
SQL> exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname=>'T0403A',estimate_percent=>100);
PL/SQL procedure successfully completed.
SQL> set autotrace on;
SQL> select * from t0403a where id<100;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
57 12aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
12 36aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
47 38aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
40 39aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
69 42aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
59 47aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
32 48aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
31 50aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
32 58aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
69 67aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
77 68aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--为节省篇幅，截短了输出
83 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1941751419
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |97 | 5335 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T0403A |97 | 5335 | 4 (0)| 00:00:01 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"<100)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
22 consistent gets
0 physical reads
0 redo size
6183 bytes sent via SQL*Net to client
579 bytes received via SQL*Net from client
7 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
83 rows processed
SQL> select * from t0403a where id<6;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 433aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 704aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Execution Plan
----------------------------------------------------------
Plan hash value: 1941751419
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 165 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T0403A | 3 | 165 | 4 (0)| 00:00:01 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"<6)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
750 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
--不断实验，发现直至ID<5，实际输出行为1行时，即大约为总记录的千分之一时，才使用了索引。
SQL> select * from t0403a where id<5;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 433aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Execution Plan
----------------------------------------------------------
Plan hash value: 2057097983
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 110 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T0403A | 2 | 110 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_T0403A | 2 | | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"<5)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
641 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select * from t0403a where id<6;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 433aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 704aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Execution Plan
----------------------------------------------------------
Plan hash value: 1941751419
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 165 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T0403A | 3 | 165 | 4 (0)| 00:00:01 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"<6)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
750 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
SQL> set autotrace off
--查看索引的聚簇因子，为873
SQL> select clustering_factor from user_indexes where index_name='IND_T0403A';
CLUSTERING_FACTOR
-----------------
873
--查看表中数据使用的数据块的数量，为9个。
SQL> select blocks from user_tables where table_name='T0403A';
BLOCKS
----------
9
--再实验一下数据的存放顺序与索引的顺序高度一致的情况
SQL> drop table t0403a purge;
Table dropped.
SQL> create table t0403a as select rownum id,rpad(rownum,50,'a') col1 from dual connect by rownum<=1000;
Table created.
SQL> create index ind_t0403a on t0403a(id);
Index created.
SQL> exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname=>'T0403A',estimate_percent=>100);
PL/SQL procedure successfully completed.
--此时索引的聚簇因子为9
SQL> select clustering_factor from user_indexes where index_name='IND_T0403A';
CLUSTERING_FACTOR
-----------------
9
--表大小没有变化，所以，表中数据所占用的数据块数仍为9
SQL> select blocks from user_tables where table_name='T0403A';
BLOCKS
----------
9
--再看一下这时，索引的表现
SQL> set autotrace on;
SQL> select * from t0403a where id<100;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 1aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2 2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
3 3aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4 4aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 5aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
6 6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
7 7aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
8 8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
9 9aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10 10aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
11 11aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--为节省篇幅，截短了输出
99 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2057097983
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 99 | 5445 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T0403A | 99 | 5445 | 3 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_T0403A | 99 | | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"<100)
Statistics
----------------------------------------------------------
10 recursive calls
0 db block gets
36 consistent gets
0 physical reads
0 redo size
7589 bytes sent via SQL*Net to client
590 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
99 rows processed
--从上可见，当输出行数为99行，占表中总行数的近10%时，仍可以使用索引。
--而且，继续不断尝试，发现直至id<223,输出行数为222行时，占表中总行数约22%时，仍可以使用索引。
SQL> select * from t0403a where id<223;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 1aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2 2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
3 3aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4 4aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 5aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
6 6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
7 7aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
8 8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
9 9aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10 10aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
11 11aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--为节省篇幅，截短了输出
222 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2057097983
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 222 | 12210 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T0403A | 222 | 12210 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_T0403A | 222 | | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"<223)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
34 consistent gets
0 physical reads
0 redo size
16455 bytes sent via SQL*Net to client
678 bytes received via SQL*Net from client
16 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
222 rows processed
SQL> select * from t0403a where id<224;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 1aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2 2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
3 3aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4 4aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 5aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
6 6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
7 7aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
8 8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
9 9aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10 10aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
11 11aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--为节省篇幅，截短了输出
223 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1941751419
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 223 | 12265 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T0403A | 223 | 12265 | 4 (0)| 00:00:01 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"<224)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
26 consistent gets
0 physical reads
0 redo size
15679 bytes sent via SQL*Net to client
678 bytes received via SQL*Net from client
16 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
223 rows processed
SQL>
通过以上实验，说明索引的聚簇因子，会严重影响索引能否被使用。当表中数据的存储顺序与索引的排列顺序差异较大时，几乎只有单行返回的查询语句才能用上索引。反之，当表中数据的存储顺序与索引的排列顺序高度一致时，即使返回的行数占总行数的超过20%，仍可以用到索引。
但为什么会这样呢，这是因为当使用聚簇因子较高的索引时，其COST较高，当其高于全表扫描的代价时，CBO就会选择此时COST更小的全表扫描方法了。
CBO在计算索引范围扫描（IRS）的成本时，使用如下的公式：
IRS COST=I/O COST + CPU COST
其中I/O COST=INDEX ACCESS I/O COST + TABLE ACCESS I/O COST
进一步:
INDEX ACCESS I/O COST=BLEVEL+CEIL(#LEAF_BLOCKS*IX_SEL)
TABLE ACCESS I/O COST=CEIL(CLUSTERING_FACTOR*IX_SEL_WITH_FILTERS)
这就可以看到，对于一个使用同样的SQL创建的索引，其IX_SEL（索引选择率）和IX_SEL_WITH_FILTERS(带过滤的索引选择率）（注1）是一样的。但如上面实验上所示，索引是一样的，但如果数据的存放顺序是不一样的，其聚簇因子是会相差很大的。所以，我们可以得到的第一个推论就是：索引的聚簇因子越大，其进行索引范围扫描的COST越大。
注1：写此博文时，未找到对“IX_SEL_WITH_FILTERS”的明确解释，所以，仅从字面上进行了翻译和理解。
本文出自 “大脸猫” 博客，请务必保留此出处http://bfc99.blog.51cto.com/265386/1627998
创建测试表t0403a,共两列（ID列和COL1列），其中ID列为一个1000以内的随机数。然后在ID列上创建索引。这样做的目的就是想让该索引的聚簇因子较大。因为用这种方式创建的表中数据存放顺序与ID的大小是完全不相关的，即是混乱的，不是有序的。
SQL> create table t0403a as select ceil(dbms_random.value*1000) id,rpad(rownum,50,'a') col1 from dual connect by rownum<=1000;
Table created.
SQL> create index ind_t0403a on t0403a(id);
Index created.
SQL> exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname=>'T0403A',estimate_percent=>100);
PL/SQL procedure successfully completed.
SQL> set autotrace on;
SQL> select * from t0403a where id<100;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
57 12aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
12 36aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
47 38aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
40 39aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
69 42aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
59 47aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
32 48aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
31 50aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
32 58aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
69 67aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
77 68aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--为节省篇幅，截短了输出
83 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1941751419
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |97 | 5335 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T0403A |97 | 5335 | 4 (0)| 00:00:01 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"<100)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
22 consistent gets
0 physical reads
0 redo size
6183 bytes sent via SQL*Net to client
579 bytes received via SQL*Net from client
7 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
83 rows processed
SQL> select * from t0403a where id<6;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 433aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 704aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Execution Plan
----------------------------------------------------------
Plan hash value: 1941751419
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 165 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T0403A | 3 | 165 | 4 (0)| 00:00:01 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"<6)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
750 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
--不断实验，发现直至ID<5，实际输出行为1行时，即大约为总记录的千分之一时，才使用了索引。
SQL> select * from t0403a where id<5;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 433aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Execution Plan
----------------------------------------------------------
Plan hash value: 2057097983
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 110 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T0403A | 2 | 110 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_T0403A | 2 | | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"<5)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
641 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select * from t0403a where id<6;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 433aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 704aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Execution Plan
----------------------------------------------------------
Plan hash value: 1941751419
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 165 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T0403A | 3 | 165 | 4 (0)| 00:00:01 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"<6)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
750 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
SQL> set autotrace off
--查看索引的聚簇因子，为873
SQL> select clustering_factor from user_indexes where index_name='IND_T0403A';
CLUSTERING_FACTOR
-----------------
873
--查看表中数据使用的数据块的数量，为9个。
SQL> select blocks from user_tables where table_name='T0403A';
BLOCKS
----------
9
--再实验一下数据的存放顺序与索引的顺序高度一致的情况
SQL> drop table t0403a purge;
Table dropped.
SQL> create table t0403a as select rownum id,rpad(rownum,50,'a') col1 from dual connect by rownum<=1000;
Table created.
SQL> create index ind_t0403a on t0403a(id);
Index created.
SQL> exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname=>'T0403A',estimate_percent=>100);
PL/SQL procedure successfully completed.
--此时索引的聚簇因子为9
SQL> select clustering_factor from user_indexes where index_name='IND_T0403A';
CLUSTERING_FACTOR
-----------------
9
--表大小没有变化，所以，表中数据所占用的数据块数仍为9
SQL> select blocks from user_tables where table_name='T0403A';
BLOCKS
----------
9
--再看一下这时，索引的表现
SQL> set autotrace on;
SQL> select * from t0403a where id<100;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 1aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2 2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
3 3aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4 4aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 5aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
6 6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
7 7aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
8 8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
9 9aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10 10aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
11 11aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--为节省篇幅，截短了输出
99 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2057097983
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 99 | 5445 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T0403A | 99 | 5445 | 3 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_T0403A | 99 | | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"<100)
Statistics
----------------------------------------------------------
10 recursive calls
0 db block gets
36 consistent gets
0 physical reads
0 redo size
7589 bytes sent via SQL*Net to client
590 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
99 rows processed
--从上可见，当输出行数为99行，占表中总行数的近10%时，仍可以使用索引。
--而且，继续不断尝试，发现直至id<223,输出行数为222行时，占表中总行数约22%时，仍可以使用索引。
SQL> select * from t0403a where id<223;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 1aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2 2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
3 3aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4 4aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 5aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
6 6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
7 7aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
8 8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
9 9aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10 10aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
11 11aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--为节省篇幅，截短了输出
222 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2057097983
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 222 | 12210 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T0403A | 222 | 12210 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_T0403A | 222 | | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"<223)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
34 consistent gets
0 physical reads
0 redo size
16455 bytes sent via SQL*Net to client
678 bytes received via SQL*Net from client
16 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
222 rows processed
SQL> select * from t0403a where id<224;
ID COL1
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 1aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2 2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
3 3aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4 4aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5 5aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
6 6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
7 7aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
8 8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
9 9aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10 10aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
11 11aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--为节省篇幅，截短了输出
223 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1941751419
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 223 | 12265 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T0403A | 223 | 12265 | 4 (0)| 00:00:01 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"<224)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
26 consistent gets
0 physical reads
0 redo size
15679 bytes sent via SQL*Net to client
678 bytes received via SQL*Net from client
16 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
223 rows processed
SQL>
通过以上实验，说明索引的聚簇因子，会严重影响索引能否被使用。当表中数据的存储顺序与索引的排列顺序差异较大时，几乎只有单行返回的查询语句才能用上索引。反之，当表中数据的存储顺序与索引的排列顺序高度一致时，即使返回的行数占总行数的超过20%，仍可以用到索引。
但为什么会这样呢，这是因为当使用聚簇因子较高的索引时，其COST较高，当其高于全表扫描的代价时，CBO就会选择此时COST更小的全表扫描方法了。
CBO在计算索引范围扫描（IRS）的成本时，使用如下的公式：
IRS COST=I/O COST + CPU COST
其中I/O COST=INDEX ACCESS I/O COST + TABLE ACCESS I/O COST
进一步:
INDEX ACCESS I/O COST=BLEVEL+CEIL(#LEAF_BLOCKS*IX_SEL)
TABLE ACCESS I/O COST=CEIL(CLUSTERING_FACTOR*IX_SEL_WITH_FILTERS)
这就可以看到，对于一个使用同样的SQL创建的索引，其IX_SEL（索引选择率）和IX_SEL_WITH_FILTERS(带过滤的索引选择率）（注1）是一样的。但如上面实验上所示，索引是一样的，但如果数据的存放顺序是不一样的，其聚簇因子是会相差很大的。所以，我们可以得到的第一个推论就是：索引的聚簇因子越大，其进行索引范围扫描的COST越大。
注1：写此博文时，未找到对“IX_SEL_WITH_FILTERS”的明确解释，所以，仅从字面上进行了翻译和理解。
本文出自 “大脸猫” 博客，请务必保留此出处http://bfc99.blog.51cto.com/265386/1627998
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 聚簇因子对于索引的影响
- Oracle索引梳理系列（九）- 浅谈聚簇因子对索引使用的影响及优化方法
- 索引聚簇因子
- 索引的聚簇因子分析
- oracle 聚簇因子对查询性能的影响
- oracle 聚簇因子对查询性能的影响
- oracle 聚簇因子对查询性能的影响
- 索引的聚簇因子分析
- Oracle的聚簇因子对于查询IO的影响
- 通过实验分析索引对MySQL插入时性能的影响
- mysql 字段类型对查询效率的影响实验及小范围取值字段不宜添加索引
- nice值影响进程调度的实验，在多核cpu上
- sql server 索引阐述系列七 索引填充因子与碎片
- 是什么影响了数据库索引选型？
- order by多个字段对索引的影响
- 索引对查询条件顺序的影响
- 冷备数据库能否追溯应用旧库归档日志呢?通过实验来寻找答案!
- 实验证明突然修改网站标题不影响网站排名
- 对oracle中drop和truncate对表占用空间和索引占用空间的影响不同的研究
- 测试分区维护对于字段索引的影响（包括本地/全局索引分区与普通分区）