摘要：今天為什么提到這個(gè)話題，出于一個(gè)偶然，一個(gè)同事在優(yōu)化新開(kāi)發(fā)的系統(tǒng)時(shí)向我請(qǐng)教如何添加復(fù)合壓縮索引的問(wèn)題。我總結(jié)了一下，問(wèn)題有三。

第一：需不需要壓縮

第二：對(duì)第幾列壓縮

第三：性能對(duì)比，選出最優(yōu)

好，問(wèn)題提出我們一一來(lái)解答一下

?

1.場(chǎng)景

在我的文章中經(jīng)常會(huì)看到這個(gè)詞，當(dāng)然也可以不談場(chǎng)景說(shuō)技術(shù)，但我覺(jué)的那只是隔空建樓，毫無(wú)目的，沒(méi)有根據(jù)性。我們?cè)谏钊胙芯康臅r(shí)候要避免這樣的盲目討論，效果也不會(huì)好太多。注重技術(shù)的應(yīng)用場(chǎng)景，才是研究技術(shù)、應(yīng)用技術(shù)之根本，不管多么高科技的東東，或者說(shuō)多牛的技術(shù)，最終還是要落到實(shí)處。那么本節(jié)講的“復(fù)合壓縮索引”的使用場(chǎng)景常用在，where子句中同時(shí)查詢多列的情況下可以創(chuàng)建。如果要是有的列上數(shù)據(jù)重復(fù)度較高可以考慮進(jìn)行壓縮，重復(fù)度越高壓縮效果越好，索引壓縮以后一個(gè)索引塊可以存放更多的鍵值。今天我們遇到的情況就和上述差不多。簡(jiǎn)介如下：

BB_BORROWER ?表名，這是我們需要檢索的表名

BB_BORROWER.VALIDITYFLAG ?VARCHAR2(5)列名，數(shù)據(jù)有效狀態(tài)，此列只有三個(gè)值“1”“2”“3”

特點(diǎn)：列的基數(shù)不多且重復(fù)值極高

BB_BORROWER.FINANCECODE ?VARCHAR2(14)列名，金融機(jī)構(gòu)代碼，此列相對(duì)來(lái)講基數(shù)略大，大到多少呢->1000家，這是征信管理局今年審批過(guò)的機(jī)構(gòu)數(shù)，可能有的朋友會(huì)問(wèn)，此列要不要壓縮啊，實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)，經(jīng)過(guò)測(cè)試后才能得到答案。

?

2.復(fù)合壓縮索引語(yǔ)法

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

compress后面跟的數(shù)字表示前綴的深度，也就是需要用來(lái)壓縮的columns數(shù)

例

create index idx_leo on t(a,b,c) compress1; ??只壓縮第一列

create index idx_leo on t(a,b,c) compress2; ??對(duì)前兩列進(jìn)行壓縮

create index idx_leo on t(a,b,c) compress3; ??對(duì)前三列進(jìn)行壓縮

?

3.查看動(dòng)態(tài)性能視圖指標(biāo)

官方文檔?books：Reference->INDEX_STATS

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

btree_space：B-tree索引當(dāng)前分配的空間

used_space：分配空間中已經(jīng)被使用的部分

height：B-tree索引的高度（層數(shù)）

br_blks：B-tree索引的分支塊數(shù)，分支塊不能夠被壓縮

lf_blks：B-tree索引的葉子塊數(shù)，葉子塊能夠被壓縮

opt_cmpr_count：列中關(guān)鍵字最小的壓縮長(zhǎng)度

?

4.實(shí)驗(yàn)

（1）非壓縮復(fù)合索引

drop index idx_bb_borrower1;

create index idx_bb_borrower1on bb_borrower(validityflag,financecode);

SQL> analyze index idx_bb_borrower1validate structure; ? ? ? ? ? ??分析索引結(jié)構(gòu)

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）只壓縮第一列的復(fù)合壓縮索引

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; ? ? ? ? ?分析索引結(jié)構(gòu)

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）壓縮前兩列復(fù)合壓縮索引

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; ? ? ? ? ?分析索引結(jié)構(gòu)

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

最后分析表并級(jí)聯(lián)索引

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

PL/SQL procedure successfully completed

附：如果索引之前已經(jīng)創(chuàng)建完畢，rebuildindex可重建壓縮索引&恢復(fù)為普通索引之方法

alterindex idx_bb_borrower1 rebuild compress;

alterindex idx_bb_borrower1 rebuild nocompress;

?

5.結(jié)論

我們現(xiàn)在對(duì)上述三個(gè)實(shí)驗(yàn)結(jié)果進(jìn)行對(duì)比可發(fā)現(xiàn)“對(duì)前兩列進(jìn)行壓縮”效果最好，如果表中記錄越多，那么測(cè)試的效果越顯著。

復(fù)合壓縮索引優(yōu)勢(shì)

（1）對(duì)鍵值重復(fù)度越高的列壓縮效果越好，可以節(jié)省更多的存儲(chǔ)空間

（2）索引壓縮后一個(gè)索引塊可以存放更多的索引鍵值

（3）掃描同樣的記錄數(shù)物理IO更少

（4）提高緩沖區(qū)命中率

復(fù)合壓縮索引不足

（1）索引更新時(shí)需要重新解壓->更新->加壓，使用更多的CPU資源，維護(hù)成本高

（2）索引查詢時(shí)需要更多的CPU計(jì)算時(shí)長(zhǎng)，解壓后才能比較查詢

（3）熱塊競(jìng)爭(zhēng)，當(dāng)查詢的結(jié)果集都集中在一個(gè)塊中時(shí)會(huì)引起熱塊

（4）爭(zhēng)用更多的CPU資源

小結(jié)：索引壓縮技術(shù)是否可以幫助提升總體性能，這就需要根據(jù)實(shí)際硬件資源來(lái)具體分析了。在IO資源與CPU資源之間做好取舍，經(jīng)過(guò)實(shí)際測(cè)試后得出結(jié)論。由此看出，一種技術(shù)的使用必然離不開(kāi)它所應(yīng)用的場(chǎng)景，使用的效果也要根據(jù)當(dāng)時(shí)的場(chǎng)景具體問(wèn)題具體分析。

注：bitmap索引不能壓縮

轉(zhuǎn)載于:https://www.cnblogs.com/zfox2017/p/7997993.html

總結(jié)

以上是生活随笔為你收集整理的转://Oracle 复合压缩索引场景及性能对比的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。