5.    重建B树索引

5.1如何重建B树索引

重建索引有两种方法：一种是最简单的，删除原索引，然后重建；第二种是使用ALTER INDEX … REBUILD命令对索引进行重建。第二种方式是从oracle 7.3.3版本开始引入的，从而使得用户在重建索引时不必删除原索引再重新CREATE INDEX了。ALTER INDEX … REBUILD相对CREATE INDEX有以下好处：

1） 它使用原索引的叶子节点作为新索引的数据来源。我们知道，原索引的叶子节点的数据块通常都要比表里的数据块要少很多，因此进行的I/O就会减少；同时，由于原索引的叶子节点里的索引条目已经排序了，因此在重建索引的过程中，所做的排序工作也要少的多。

2） 自从oracle 8.1.6以来，ALTER INDEX … REBUILD命令可以添加ONLINE短语。这使得在重建索引的过程中，用户可以继续对原来的索引进行修改，也就是说可以继续对表进行DML操作。

而同时，ALTER INDEX … REBUILD与CREATE INDEX也有很多相同之处：

1） 它们都可以通过添加PARALLEL提示进行并行处理。

2） 它们都可以通过添加NOLOGGING短语，使得重建索引的过程中产生最少的重做条目（redo entry）。

3） 自从oracle 8.1.5以来，它们都可以田间COMPUTE STATISTICS短语，从而在重建索引的过程中，就生成CBO所需要的统计信息，这样就避免了索引创建完毕以后再次运行analyze或dbms_stats来收集统计信息。

当我们重建索引以后，在物理上所能获得的好处就是能够减少索引所占的空间大小（特别是能够减少叶子节点的数量）。而索引大小减小以后，又能带来以下若干好处：

1） CBO对于索引的使用可能会产生一个较小的成本值，从而在执行计划中选择使用索引。

2） 使用索引扫描的查询扫描的物理索引块会减少，从而提高效率。

3） 由于需要缓存的索引块减少了，从而让出了内存以供其他组件使用。

尽管重建索引具有一定的好处，但是盲目的认为重建索引能够解决很多问题也是不正确的。比如我见过一个生产系统，每隔一个月就要重建所有的索引（而且我相信，很多生产系统可能都会这么做），其中包括一些100GB的大表。为了完成重建所有的索引，往往需要把这些工作分散到多个晚上进行。事实上，这是一个7×24的系统，仅重建索引一项任务就消耗了非常多的系统资源。但是每隔一段时间就重建索引有意义吗？这里就有一些关于重建索引的很流行的说法，主要包括：

1） 如果索引的层级超过X（X通常是3）级以后需要通过重建索引来降低其级别。

2） 如果经常删除索引键值，则需要定时重建索引来收回这些被删除的空间。

3） 如果索引的clustering_factor很高，则需要重建索引来降低该值。

4） 定期重建索引能够提高性能。

对于第一点来说，我们在前面已经知道，B树索引是一棵在高度上平衡的树，所以重建索引基本不可能降低其级别，除非是极特殊的情况导致该索引有非常大量的碎片，导致B树索引“虚高”，那么这实际又来到第二点上（因为碎片通常都是由于删除引起的）。实际上，对于第一和第二点，我们应该通过运行ALTER INDEX … REBUILD命令以后检查indest_stats.pct_used字段来判断是否有必要重建索引。

5.2重建B树索引对于clustering_factor的影响

而对于clustering_factor来说，它是用来比较索引的顺序程度与表的杂乱排序程度的一个度量。Oracle在计算某个clustering_factor时，会对每个索引键值查找对应到表的数据，在查找的过程中，会跟踪从一个表的数据块跳转到另外一个数据块的次数（当然，它不可能真的这么做，源代码里只是简单的扫描索引，从而获得ROWID，然后从这些ROWID获得表的数据块的地址）。每一次跳转时，有个计数器就会增加，最终该计数器的值就是clustering_factor。下图四描述了这个原理。

                                                                          图四             

      在上图四中，我们有一个表，该表有4个数据块，以及20条记录。在列N1上有一个索引，上图中的每个小黑点就表示一个索引条目。列N1的值如图所示。而N1的索引的叶子节点包含的值为：A、B、C、D、E、F。如果oracle开始扫描索引的底部，叶子节点包含的第一个N1值为A，那么根据该值可以知道对应的ROWID位于第一个数据块的第三行里，所以我们的计数器增加1。同时，A值还对应第二个数据块的第四行，由于跳转到了不同的数据块上，所以计数器再加1。同样的，在处理B时，可以知道对应第一个数据块的第二行，由于我们从第二个数据块跳转到了第一个数据块，所以计数器再加1。同时，B值还对应了第一个数据块的第五行，由于我们这里没有发生跳转，所以计数器不用加1。

在上面的图里，在表的每一行的下面都放了一个数字，它用来显示计数器跳转到该行时对应的值。当我们处理完索引的最后一个值时，我们在数据块上一共跳转了十次，所以该索引的clustering_factor为10。

注意第二个数据块，clustering_factor为8出现了4次。因为在索引里N1为E所对应的4个索引条目都指向了同一个数据块。从而使得clustering_factor不再增长。同样的现象出现在第三个数据块中，它包含三条记录，它们的值都是C，对应的clustering_factor都是6。

从clustering_factor的计算方法上可以看出，我们可以知道它的最小值就等于表所含有的数据块的数量；而最大值就是表所含有的记录的总行数。很明显，clustering_factor越小越好，越小说明通过索引查找表里的数据行时需要访问的表的数据块越少。

我们来看一个例子，来说明重建索引对于减小clustering_factor没有用处。首先我们创建一个测试表：

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

SQL> create index idx_clustfact_test on clustfact_test(id);

然后，我们插入十万条记录。

SQL> begin

 2           for i in 1..100000 loop

 3                   insert into clustfact_test values(mod(i,200),to_char(i));

 4           end loop;

 5           commit;

 6 end;

 7 /

因为使用了mod的关系，最终数据在表里排列的形式为：

0,1,2,3,4,5,…,197,198,199,0,1,2,3,…, 197,198,199,0,1,2,3,…, 197,198,199,0,1,2,3,…

      接下来，我们分析表。

SQL> exec dbms_stats.gather_table_stats(user,’clustfact_test’,cascade=>true);

      这个时候，我们来看看该索引的clustering_factor。

SQL> select num_rows, blocks from user_tables where table_name = ‘CLUSTFACT_TEST’;

 NUM_ROWS    BLOCKS

———- ———-

   100000       202

SQL> select num_rows, distinct_keys, avg_leaf_blocks_per_key, avg_data_blocks_per_key,

 2 clustering_factor from user_indexes where index_name = ‘IDX_CLUSTFACT_TEST’;

 NUM_ROWS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR

———- ————- ———————– ———————– —————–

   100000          200                      1                    198            39613

      从上面的avg_data_blocks_per_key的值为198可以知道，每个键值平均分布在198个数据块里，而整个表也就202个数据块。这也就是说，要获取某个键值的所有记录，几乎每次都需要访问所有的数据块。从这里已经可以猜测到clustering_factor会非常大。事实上，该值近4万，也说明该索引并不会很有效。

      我们来看看下面这句SQL语句的执行计划。

SQL> select count(name) from clufac_test where id = 100;

Execution Plan

———————————————————-

  0     SELECT STATEMENT ptimizer=CHOOSE (Cost=32 Card=1 Bytes=9)

  1   0  SORT (AGGREGATE)

  2   1    TABLE ACCESS (FULL) OF ‘CLUFAC_TEST’ (Cost=32 Card=500 Bytes=4500)

Statistics

———————————————————-

         0 recursive calls

         0 db block gets

       205 consistent gets

……

      很明显，CBO弃用了索引，而使用了全表扫描。这实际上已经说明由于索引的clustering_factor过高，导致通过索引获取数据时跳转的数据块过多，成本过高，因此直接使用全表扫描的成本会更低。

      这时我们来重建索引看看会对clustering_factor产生什么影响。从下面的测试中可以看到，没有任何影响。

SQL> alter index idx_clustfact_test rebuild;

SQL> select num_rows, distinct_keys, avg_leaf_blocks_per_key, avg_data_blocks_per_key,

 2 clustering_factor from user_indexes where index_name = ‘IDX_CLUSTFACT_TEST’;

 NUM_ROWS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR

———- ————- ———————– ———————– —————–

   100000          200                      1                    198            39613

      那么当我们将表里的数据按照id的顺序（也就是索引的排列顺序）重建时，该SQL语句会如何执行？

SQL> create table clustfact_test_temp as select * from clustfact_test order by id;

SQL> truncate table clustfact_test;

SQL> insert into clustfact_test select * from clustfact_test_temp;

SQL> exec dbms_stats.gather_table_stats(user,’clustfact_test’,cascade=>true);

SQL> select num_rows, distinct_keys, avg_leaf_blocks_per_key, avg_data_blocks_per_key,

 2 clustering_factor from user_indexes where index_name = ‘IDX_CLUSTFACT_TEST’;

 NUM_ROWS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR

———- ————- ———————– ———————– —————–

   100000          200                      1                      1              198

      很明显的，这时的索引里每个键值只分布在1个数据块里，同时clustering_factor也已经降低到了198。这时再次执行相同的查询语句时，CBO将会选择索引，同时可以看到consistent gets也从205降到了5。

SQL> select count(name) from clustfact_test where id = 100;

Execution Plan

———————————————————-

  0     SELECT STATEMENT ptimizer=CHOOSE (Cost=2 Card=1 Bytes=9)

  1   0  SORT (AGGREGATE)

  2   1    TABLE ACCESS (BY INDEX ROWID) OF ‘CLUSTFACT_TEST’ (Cost=2 Card=500 Bytes=4500)

  3   2      INDEX (RANGE SCAN) OF ‘IDX_CLUSTFACT_TEST’ (NON-UNIQUE) (Cost=1 Card=500)

Statistics

———————————————————-

         0 recursive calls

         0 db block gets

         5 consistent gets

……

      所以我们可以得出结论，如果仅仅是为了降低索引的clustering_factor而重建索引没有任何意义。降低clustering_factor的关键在于重建表里的数据。只有将表里的数据按照索引列排序以后，才能切实有效的降低clustering_factor。但是如果某个表存在多个索引的时候，需要仔细决定应该选择哪一个索引列来重建表。 

本文转自 
http://space.itpub.net/?uid-9842-action-viewspace-itemid-324587

.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);

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

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

      上面是对最好的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);