《Oracle 复合压缩索引场景及性能对比》-原理引航-实例演示

《Oracle 复合压缩索引场景及性能对比》

摘要：今天为什么提到这个话题，出于一个偶然，一个同事在优化新开发的系统时向我请教如何添加复合压缩索引的问题。我总结了一下，问题有三。

第一：需不需要压缩

第二：对第几列压缩

第三：性能对比，选出最优

好，问题提出我们一一来解答一下

1.场景

在我的文章中经常会看到这个词，当然也可以不谈场景说技术，但我觉的那只是隔空建楼，毫无目的，没有根据性。我们在深入研究的时候要避免这样的盲目讨论，效果也不会好太多。注重技术的应用场景，才是研究技术、应用技术之根本，不管多么高科技的东东，或者说多牛的技术，最终还是要落到实处。那么本节讲的“复合压缩索引”的使用场景常用在，where子句中同时查询多列的情况下可以创建。如果要是有的列上数据重复度较高可以考虑进行压缩，重复度越高压缩效果越好，索引压缩以后一个索引块可以存放更多的键值。今天我们遇到的情况就和上述差不多。简介如下：

BB_BORROWER  表名，这是我们需要检索的表名

BB_BORROWER.VALIDITYFLAG  VARCHAR2(5)列名，数据有效状态，此列只有三个值“1”“2”“3”

特点：列的基数不多且重复值极高

BB_BORROWER.FINANCECODE  VARCHAR2(14)列名，金融机构代码，此列相对来讲基数略大，大到多少呢->1000家，这是征信管理局今年审批过的机构数，可能有的朋友会问，此列要不要压缩啊，实践是检验真理的唯一标准，经过测试后才能得到答案。

2.复合压缩索引语法

create index 索引名 on 表名（列名） compress  1;

compress后面跟的数字表示前缀的深度，也就是需要用来压缩的columns数

例

create index idx_leo on t(a,b,c) compress1;   只压缩第一列

create index idx_leo on t(a,b,c) compress2;   对前两列进行压缩

create index idx_leo on t(a,b,c) compress3;   对前三列进行压缩

3.查看动态性能视图指标

官方文档 books：Reference->INDEX_STATS

selectbtree_space,used_space,height,br_blks,lf_blks,opt_cmpr_count from index_stats;

btree_space：B-tree索引当前分配的空间

used_space：分配空间中已经被使用的部分

height：B-tree索引的高度（层数）

br_blks：B-tree索引的分支块数，分支块不能够被压缩

lf_blks：B-tree索引的叶子块数，叶子块能够被压缩

opt_cmpr_count：列中关键字最小的压缩长度

4.实验

（1）非压缩复合索引

drop index idx_bb_borrower1;

create index idx_bb_borrower1on bb_borrower(validityflag,financecode);

SQL> analyze index idx_bb_borrower1validate structure;             分析索引结构

Index analyzed

SQL> selectbtree_space,used_space,height,br_blks,lf_blks,opt_cmpr_count from index_stats;

BTREE_SPACE    USED_SPACE   HEIGHT   BR_BLKS    LF_BLKS     OPT_CMPR_COUNT

----------- -------------------- ---------- ---------- ------------------ -------------------- ---------- ---------- --------

            7996     868                 1             0                1                 2

（2）只压缩第一列的复合压缩索引

SQL> drop index idx_bb_borrower1;

Index dropped

SQL> create index idx_bb_borrower1 onbb_borrower(validityflag,financecode) compress 1;

Index created

SQL> analyze index idx_bb_borrower1validate structure;          分析索引结构

Index analyzed

SQL> select btree_space,used_space,height,br_blks,lf_blks,opt_cmpr_countfrom index_stats;

BTREE_SPACE     USED_SPACE    HEIGHT    BR_BLKS    LF_BLKS         OPT_CMPR_COUNT

----------- ---------- -------------------- ---------- ---------------------- ---------- ---------- ------------------------

           7992       830                  1               0               1                     2

（3）压缩前两列复合压缩索引

drop index idx_bb_borrower1;

create index idx_bb_borrower1 onbb_borrower(validityflag,financecode) compress 2;

SQL> drop index idx_bb_borrower1;

Index dropped

SQL> create index idx_bb_borrower1 onbb_borrower(validityflag,financecode) compress 2;

Index created

SQL> analyze indexidx_bb_borrower1 validate structure;          分析索引结构

Index analyzed

SQL> selectbtree_space,used_space,height,br_blks,lf_blks,opt_cmpr_count from index_stats;

BTREE_SPACE     USED_SPACE   HEIGHT    BR_BLKS   LF_BLKS      OPT_CMPR_COUNT

----------- ---------- -------------------- ---------- ---------------------- ---------- ---------- ------------------------

           7992       571                 1               0               1                  2

最后分析表并级联索引

SQL> executedbms_stats.gather_table_stats('sfcp','bb_borrower',cascade=>true);

PL/SQL procedure successfully completed

附：如果索引之前已经创建完毕，rebuildindex可重建压缩索引&恢复为普通索引之方法

alterindex idx_bb_borrower1 rebuild compress;

alterindex idx_bb_borrower1 rebuild nocompress;

5.结论

我们现在对上述三个实验结果进行对比可发现“对前两列进行压缩”效果最好，如果表中记录越多，那么测试的效果越显著。

复合压缩索引优势

（1）对键值重复度越高的列压缩效果越好，可以节省更多的存储空间

（2）索引压缩后一个索引块可以存放更多的索引键值

（3）扫描同样的记录数物理IO更少

（4）提高缓冲区命中率

复合压缩索引不足

（1）索引更新时需要重新解压->更新->加压，使用更多的CPU资源，维护成本高

（2）索引查询时需要更多的CPU计算时长，解压后才能比较查询

（3）热块竞争，当查询的结果集都集中在一个块中时会引起热块

（4）争用更多的CPU资源

小结：索引压缩技术是否可以帮助提升总体性能，这就需要根据实际硬件资源来具体分析了。在IO资源与CPU资源之间做好取舍，经过实际测试后得出结论。由此看出，一种技术的使用必然离不开它所应用的场景，使用的效果也要根据当时的场景具体问题具体分析。

注：bitmap索引不能压缩

复合 压缩 索引 场景 性能

 本文转自 ztfriend 51CTO博客，原文链接：http://blog.51cto.com/leonarding/1389255，如需转载请自行联系原作者