oracle随笔-Index (B*树索引-2)

B* Tree索引有一个很有趣味性的工作——索引键压缩。开始解说前我先执行一系列的SQL语句。

首先运行以下SQL代码段

analyze index t_idx validate structure;
create table IDX_STATS
as
select 'nocompress' description,a.* from index_stats a;

执行完以上代码后运行如下代码4次，参数分别是1,2,3,3.

drop index t_idx;
create index t_idx on t(RECNUM,OPTYPENUM,RECYEAR) compress &1;
analyze index t_idx validate structure;
insert into idx_stats
select 'compress &1' description,a.* from index_stats a;
commit;
 

运行如下语句查看执行结果：

select description,height,blocks,LF_blks,btree_space,opt_cmpr_count,opt_cmpr_pctsave from idx_stats

这是我本机的运行结果。分析如下：

第一行是没有压缩的数据，信息显示索引树的高度是3，共有1024个数据块，使用的空间占用了7384096个字节，系统给出的建议压缩次数为1，压缩后大约节约的空间为0.16，初步估算一下第一次压缩后的数据量应该为7384096*（1-0.16）=6202640。

第二行为执行一次压缩后数据信息。索引树高度没有变化。数据块有原来的1024减少为896，所占空间为6165024，这个数据和当初估算的值非常的接近了。通过运算发现实际节约空间16.51%。这个数据符合系统统计的结果。观察第二次和第三次压缩后数据

可以发现在第二次和第三次压缩使得数据的空间不仅没有相应的减少反而增加了，通过运算发现opt_cmpr_pctsave给出的值也相当精确。（9403440-6165024）/9403440约等于0.34。出现以上原因通过下面的图示来说明：

假如每一格对应一块存储空间，在未压缩的数据中一共有27格，而第一次压缩后剩余21格。oracle索引键的压缩基本原理就是这样，通过提取键条中的共有信息存储，来压缩空间。

通过压缩索引可以有效的减少IO访问次数，每个索引块上存储的数据相对集中，这样索引在查找的过程中也会更快捷。带来的问题是需要占用更多的cpu时间。至于第一次压缩后为什么后面的压缩会越来越大，很简单，每次压缩都需要有一个附加一个指针信息用于指向共有的前缀。第一次压缩后大部分键条都达到了唯一，后面再次压缩唯一的键条都会附加一个4字节的指针，这样就增加了空间。