首先，我們結合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 --

【實驗】【索引壓縮】索引壓縮演示及優缺點總結

相關文章