压缩索引(compress index)

george.ma

压缩索引基本介绍

基本语法
create index <index_name> on <table>(column,column...) compress <数字，并小于等于索引包括的字段值>;
如create index t_objects_idx on t_objects(owner,object_type,object_name) compress 2;即表示压缩前面的二个字段

 

键索引（compressed key index）的基本概念是，每个键条目分解为两个部分：“前缀”和“后缀”。前缀建立在串联索引（concatenated index）的前几列上，这些列有许多重复的值。后缀则在索引键的后几列上，这是前缀所在索引条目中的惟一部分（即有区别的部分）。
    将创建一个表和一个串联索引，并使用ANALYZE INDEX测量无压缩时所用的空间。然后利用索引压缩创建这个索引，分别压缩不同数目的键条目，查看有什么差别：
 create table  t_objects as select * from all_objects;
create index  t_objects_idx on t_objects(owner,object_type,object_name);
analyze index t_idx validate structure;
然后创建一个INX_STATS表，用来保存INDEX_STATS信息，我们把表中的行标记为“未压缩”（noncompressed）：
create table idx_stats as
select 'noncompressed' what, a.* from index_stats a;

drop index t_objects_idx;
create index t_objects_idx on
t_objects(owner,object_type,object_name) --3个字段
compress &1;              ---分别输入1，2，3

analyze index t_objects_idx validate structure;

insert into idx_stats
select 'compress &2', a.*
from index_stats a;

select what, height, lf_blks, br_blks,
 btree_space, opt_cmpr_count, opt_cmpr_pctsave
 from idx_stats;

WHAT              HEIGHT    LF_BLKS    BR_BLKS BTREE_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
------------- ---------- ---------- ---------- ----------- -------------- ----------------
noncompressed          3        362          3     2920096              2               28
compress 1             3        321          3     2590812              2               19
compress 2             3        258          3     2087064              2                0
compress 3             3        404          3     3254480              2               35
    可以看到，COMPRESS 1索引的大小大约是无压缩索引的89%（通过比较BTREE_SPACE得出）。叶子块数大幅度下降。更进一步，使用COMPRESS 2时，节省的幅度更为显著。所得到的索引大约是原索引（无压缩索引）的70%，而且由于数据量减少，利用列OPT_CMPR_PCTSAVE的信息（这代表最优的节省压缩百分比（optimum compression percent saved）或期望从压缩得到的节省幅度）。我们可以猜测出COMPRESS 2索引的大小。

注意 对无压缩索引执行ANALYZE命令时，会填写OPT_CMPR_PCTSAVE/OPT_CMPR_COUNT列，并估计出：利用COMPRESS 2，可以节省28%的空间；而事实确实如此，我们果真节省了大约这么多的空间。
    不过，再看看COMPRESS 3会怎么样。如果压缩3列，所得到的索引实际上会更大：是原来索引大小的110%。这是因为：每删除一个重复的前缀，能节省N个副本的空间，但是作为压缩机制的一部分，这会在叶子块上增加4字节的开销。把OBJECT_NAME列增加到压缩键后，则使得这个键是惟一的；在这种情况下，则说明没有重复的副本可以提取。因此，最后的结果就是：我们只是向每个索引键条目增加了4个字节，而不能提取出任何重复的数据。IDX_STATS中的OPT_CMPR_COUNT列真是精准无比，确实给出了可用的最佳压缩数，OPT_COMPR_PCTSAVE则指出了可以得到多大的节省幅度。