代码改变世界

Oracle:索引列压缩的分析对比

2011-09-21 13:39  Tracy.  阅读(3185)  评论(0编辑  收藏  举报

首先,我们结合index_stats得到的索引分析数据看一下,在不同索引列压缩情况下的效果。然后统一总结实验效果。

1.创建测试用表t_compress_index
create table t_compress_index as select * from all_objects;

2.不使用索引压缩技术创建索引
sec@secooler> create index idx_t_compress_index on t(owner,object_type,object_name);

Index created.

sec@secooler> analyze index idx_t_compress_index validate structure;

Index analyzed.

sec@secooler> select height, lf_blks, br_blks, btree_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;

HEIGHT LF_BLKS BR_BLKS BTREE_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
------ ------- ------- ----------- -------------- ----------------
2 64 1 519772 2 28

3.尝试只使用第一列进行压缩
sec@secooler> drop index idx_t_compress_index;

Index dropped.

sec@secooler> create index idx_t_compress_index on t(owner,object_type,object_name) compress 1;

Index created.

sec@secooler> analyze index idx_t_compress_index validate structure;

Index analyzed.

sec@secooler> select height, lf_blks, br_blks, btree_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;

HEIGHT LF_BLKS BR_BLKS BTREE_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
------ ------- ------- ----------- -------------- ----------------
2 56 1 455580 2 18

4.尝试使用前两列进行压缩
sec@secooler> drop index idx_t_compress_index;

Index dropped.

sec@secooler> create index idx_t_compress_index on t(owner,object_type,object_name) compress 2;

Index created.

sec@secooler> analyze index idx_t_compress_index validate structure;

Index analyzed.

sec@secooler> select height, lf_blks, br_blks, btree_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;

HEIGHT LF_BLKS BR_BLKS BTREE_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
------ ------- ------- ----------- -------------- ----------------
2 46 1 375660 2 0

5.尝试使用前三列进行压缩
sec@secooler> drop index idx_t_compress_index;

Index dropped.

sec@secooler> create index idx_t_compress_index on t(owner,object_type,object_name) compress 3;

Index created.

sec@secooler> analyze index idx_t_compress_index validate structure;

Index analyzed.

sec@secooler> select height, lf_blks, br_blks, btree_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;

HEIGHT LF_BLKS BR_BLKS BTREE_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
------ ------- ------- ----------- -------------- ----------------
2 73 1 591444 2 36

6.注意:因为索引列之后三个,所以记住不能使用compress 4进行压缩,这个是显然滴~~
sec@secooler> drop index idx_t_compress_index;

Index dropped.

sec@secooler> create index idx_t_compress_index on t(owner,object_type,object_name) compress 4;
create index idx_t_compress_index on t(owner,object_type,object_name) compress 4
*
ERROR at line 1:
ORA-25194: invalid COMPRESS prefix length value

7.索引压缩小结
(1)通过上面的这个演示过程,可以得到以下结论:
1)对前两列进行压缩效果最好
2)对全部的三列压缩反倒比不使用压缩技术耗用更多的索引空间,这与压缩机制有关
3)要在实践中反复的测试,得出最佳的压缩系数

(2)索引压缩缺点:
1.维护索引时,更耗时,因为需要更多的计算
2.查询时,搜索索引需要较长的时间,因为需要更多的计算
3.需要更多的CPU处理索引
4.增加了块竞争

(3)索引压缩好处:
1.索引占用的磁盘空间少,这是显然的
2.块缓冲区缓存能存放更多的索引条目
3.缓存命中率较高
4.物理I/O较少

任何一种技术都是一种均衡各种资源后的产物,索引压缩技术就充分的体现了这方的特点,需要在disk和CPU之间做到取舍与平衡,需要具体问题具体分析。
友情提示:如果联合索引的前几列存在大量的重复数据的时候,不妨使用一下索引压缩技术。

-- The End --

魔兽就是毒瘤,大家千万不要玩。