（转）深入研究B树索引（五）续

5.3 重建 B 树索引对于查询性能的影响

       最后我们来看一下重建索引对于性能的提高到底会有什么作用。假设我们有一个表，该表具有 1 百万条记录，占用了 100000 个数据块。而在该表上存在一个索引，在重建之前的 pct_used 为 50% ，高度为 3 ，分支节点块数为 40 个，再加一个根节点块，叶子节点数为 10000 个；重建该索引以后， pct_used 为 90% ，高度为 3 ，分支节点块数下降到 20 个，再加一个根节点块，而叶子节点数下降到 5000 个。那么从理论上说：

1）  如果通过索引获取单独 1 条记录来说：

重建之前的成本： 1 个根＋ 1 个分支＋ 1 个叶子＋ 1 个表块＝ 4 个逻辑读

重建之后的成本： 1 个根＋ 1 个分支＋ 1 个叶子＋ 1 个表块＝ 4 个逻辑读

性能提高百分比： 0

2）  如果通过索引获取 100 条记录（占总记录数的 0.01% ）来说，分两种情况：

最差的 clustering_factor （即该值等于表的数据行数）：

重建之前的成本： 1 个根＋ 1 个分支＋ 0.0001*10000 （ 1 个叶子）＋ 100 个表块＝ 103 个逻辑读

重建之后的成本： 1 个根＋ 1 个分支＋ 0.0001*5000 （ 1 个叶子）＋ 100 个表块＝ 102.5 个逻辑读

性能提高百分比： 0.5% （也就是减少了 0.5 个逻辑读）

最好 clustering_factor （即该值等于表的数据块）：

重建之前的成本： 1 个根＋ 1 个分支＋ 0.0001*10000 （ 1 个叶子）＋ 0.0001*100000 （ 10 个表块）＝ 13 个逻辑读

重建之后的成本： 1 个根＋ 1 个分支＋ 0.0001*5000 （ 1 个叶子）＋ 0.0001*100000 （ 10 个表块）＝ 12.5 个逻辑读

性能提高百分比： 3.8% （也就是减少了 0.5 个逻辑读）

3）  如果通过索引获取 10000 条记录（占总记录数的 1% ）来说，分两种情况：

最差的 clustering_factor （即该值等于表的数据行数）：

重建之前的成本： 1 个根＋ 1 个分支＋ 0.01*10000 （ 100 个叶子）＋ 10000 个表块＝ 10102 个逻辑读

重建之后的成本： 1 个根＋ 1 个分支＋ 0.01*5000 （ 50 个叶子）＋ 10000 个表块＝ 10052 个逻辑读

性能提高百分比： 0.5% （也就是减少了 50 个逻辑读）

最好 clustering_factor （即该值等于表的数据块）：

重建之前的成本： 1 个根＋ 1 个分支＋ 0.01*10000 （ 100 个叶子）＋ 0.01*100000 （ 1000 个表块）＝ 1102 个逻辑读

重建之后的成本： 1 个根＋ 1 个分支＋ 0.01*5000 （ 50 个叶子）＋ 0.01*100000 （ 1000 个表块）＝ 1052 个逻辑读

性能提高百分比： 4.5% （也就是减少了 50 个逻辑读）

4）  如果通过索引获取 100000 条记录（占总记录数的 10% ）来说，分两种情况：

最差的 clustering_factor （即该值等于表的数据行数）：

重建之前的成本： 1 个根＋ 1 个分支＋ 0.1*10000 （ 1000 个叶子）＋ 100000 个表块＝ 101002 个逻辑读

重建之后的成本： 1 个根＋ 1 个分支＋ 0.1*5000 （ 500 个叶子）＋ 100000 个表块＝ 100502 个逻辑读

性能提高百分比： 0.5% （也就是减少了 500 个逻辑读）

最好 clustering_factor （即该值等于表的数据块）：

重建之前的成本： 1 个根＋ 1 个分支＋ 0.1*10000 （ 1000 个叶子）＋ 0.1*100000 （ 10000 个表块）＝ 11002 个逻辑读

重建之后的成本： 1 个根＋ 1 个分支＋ 0.1*5000 （ 500 个叶子）＋ 0.1*100000 （ 10000 个表块）＝ 10502 个逻辑读

性能提高百分比： 4.5% （也就是减少了 500 个逻辑读）

5）  对于快速全索引扫描来说，假设每次获取 8 个数据块：

重建之前的成本：（ 1 个根＋ 40 个分支＋ 10000 个叶子） / 8 ＝ 1256 个逻辑读

重建之后的成本：（ 1 个根＋ 40 个分支＋ 5000 个叶子） / 8 ＝ 631 个逻辑读
性能提高百分比： 49.8% （也就是减少了 625 个逻辑读）

       从上面有关性能提高的理论描述可以看出，对于通过索引获取的记录行数不大的情况下，索引碎片对于性能的影响非常小；当通过索引获取较大的记录行数时，索引碎片的增加可能导致对于索引逻辑读的增加，但是索引读与表读的比例保持不变；同时，我们从中可以看到， clustering_factor 对于索引读取的性能有很大的影响，并且对于索引碎片所带来的影响具有很大的作用；最后，看起来，索引碎片似乎对于快速全索引扫描具有最大的影响。

       我们来看两个实际的例子，分别是 clustering_factor 为最好和最差的两个例子。测试环境为 8KB 的数据块，表空间采用 ASSM 的管理 方式。先做一个最好的 clustering_factor 的例子，创建测试表并填充 1 百万条数据。

SQL> 
create
 
table
 rebuild_test(id number,
name
 varchar2(10));

SQL> begin

 2    for
 i 
in
 1..1000000 loop

 3        insert
 
into
 rebuild_test 
values
(i,to_char(i));

 4            if mod(i,10000)=0 then

 5                commit
;

 6            end
 if;

 7    end
 loop;

 8 end
;

 9 /

 

       该表具有 1 百万条记录，分布在 2328 个数据块中。同时由于我们的数据都是按照顺序递增插入的，所以可以知道，在 id 列上创建的索引都是具有最好的 clustering_factor 值的。我们运行以下查询测试语句，分别返回 1 、 100 、 1000 、 10000 、 50000 、 100000 以及 1000000 条记录。

select
 * 
from
 rebuild_test 
where
 id = 10;

select
 * 
from
 rebuild_test 
where
 id 
between
 100 
and
 199;

select
 * 
from
 rebuild_test 
where
 id 
between
 1000 
and
 1999;

select
 * 
from
 rebuild_test 
where
 id 
between
 10000 
and
 19999;

select
 /*+ 
index
(rebuild_test) */ * 
from
 rebuild_test 
where
 id 
between
 50000 
and
 99999;

select
 /*+ 
index
(rebuild_test) */ * 
from
 rebuild_test 
where
 id 
between
 100000 
and
 199999;

select
 /*+ 
index
(rebuild_test) */ * 
from
 rebuild_test 
where
 id 
between
 1 
and
 1000000;

select
 /*+ index_ffs(rebuild_test) */ id 
from
 rebuild_test 
where
 id 
between
 1 
and
 1000000;

 

       在运行这些测试语句前，先创建一个 pctfree 为 50% 的索引，来模拟索引碎片，分析并记录索引信息。

SQL> 
create
 
index
 idx_rebuild_test 
on
 rebuild_test(id) pctfree 50;

SQL> exec
 dbms_stats.gather_table_stats(
user
,
'rebuild_test'
,
cascade
=>
true
);

 

然后运行测试语句，记录每条查询语句所需的时间；接下来以 pctfree 为 10% 重建索引，来模拟修复索引碎片，分析并记录索引信息。

SQL> 
alter
 
index
 idx_rebuild_test rebuild pctfree 10;

SQL> exec
 dbms_stats.gather_table_stats(
user
,
'rebuild_test'
,
cascade
=>
true
);

 

接着再次运行这些测试语句，记录每条查询语句所需的时间。下表显示了两个索引信息的对比情况。

pctfree	Height	blocks	br_blks	lf_blks	pct_used	clustering_factor
50%	3	4224	8	4096	49%	2326
10%	3	2304	5	2226	90%	2326

下表显示了不同的索引下，运行测试语句所需的时间对比情况。

记录数	占记录总数的百分比	pctused(50%)	pctused(90 ％ )	性能提高百分比
1 条记录	0.0001%	0.01	0.01	0.00%
100 条记录	0.0100%	0.01	0.01	0.00%
1000 条记录	0.1000%	0.01	0.01	0.00%
10000 条记录	1.0000%	0.02	0.02	0.00%
50000 条记录	5.0000%	0.06	0.06	0.00%
100000 条记录	10.0000%	1.01	1.00	0.99%
1000000 条记录	100.0000%	13.05	11.01	15.63%
1000000 条记录 (FFS)	100.0000%	7.05	7.02	0.43%

       上面是对最好的 clustering_factor 所做的测试，那么对于最差的 clustering_factor 会怎么样呢？我们将 rebuild_test 中的 id 值反过来排列，也就是说，比如对于 id 为 3478 的记录，将 id 改为 8743 。这样的话，就将把原来按顺序排列的 id 值彻底打乱，从而使得 id 上的索引的 clustering_factor 变成最差的。为此，我写了一个函数用来反转 id 的值。

create
 
or
 
replace
 
function
 get_reverse_value(id 
in
 number) 
return
 varchar2 
is

 ls_id varchar2(10);

 ls_last_item varchar2(10);

 ls_curr_item varchar2(10);

 ls_zero varchar2(10);

 li_len integer
;

 lb_stop boolean;

begin

 ls_id := to_char(id);

 li_len := length(ls_id);

 ls_last_item := ''
;

 ls_zero := ''
;

 lb_stop := false
;

 while li_len>0 loop

       ls_curr_item := substr(ls_id,li_len,1);

       if ls_curr_item = '0'
 
and
 lb_stop = 
false
 
then

           ls_zero := ls_zero || ls_curr_item;

       else

           lb_stop := true
;

           ls_last_item:=ls_last_item||ls_curr_item;

       end
 if;

       ls_id := substr(ls_id,1,li_len-1);

       li_len := length(ls_id);

 end
 loop;

 return
(ls_last_item||ls_zero);

end
 get_reverse_value;

 

       接下来，我们创建我们第二个测试的测试表。并按照与第一个测试案例相同的方式进行测试。注意，对于测试查询来说，要把表名（包括提示里的）改为 rebuild_test_cf 。

SQL> 
create
 
table
 rebuild_test_cf 
as
 
select
 * 
from
 rebuild_test;

SQL> 
update
 rebuild_test_cf 
set
 
name
=get_reverse_value(id);