Oracle索引——位圖索引
位圖索引（bitmap index）是從Oracle7.3版本開始引入的。目前Oracle企業(yè)版和個人版都支持位圖索引，但標準版不支持。位圖索引是為數(shù)據(jù)倉庫/即席查詢環(huán)境設(shè)計的，在此所有查詢要求的數(shù)據(jù)在系統(tǒng)實現(xiàn)時根本不知道。位圖索引特別不適用于OLTP系統(tǒng)，如果系統(tǒng)中的數(shù)據(jù)會由多個并發(fā)會話頻繁地更新，這種系統(tǒng)也不適用位圖索引。
位圖索引是這樣一種結(jié)構(gòu)，其中用一個索引鍵條目存儲指向多行的指針；這與B*樹結(jié)構(gòu)不同，在B*樹結(jié)構(gòu)中，索引鍵和表中的行存在著對應(yīng)關(guān)系。在位圖索引中，可能只有很少的索引條目，每個索引條目指向多行。而在傳統(tǒng)的B*樹中，一個索引條目就指向一行。
下面假設(shè)我們要在 EMP 表的 JOB 列上創(chuàng)建一個位圖索引，如下：
Ops$tkyte@ORA10G> create BITMAP index job_idx on emp(job);
Index created.
Oracle 在索引中存儲的內(nèi)容如表 11.-6 所示。
表 11.-6 Oracle 如何存儲 JOB-IDX 位圖索引
|
值/行
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
|
ANALYST
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
1
|
0
|
1
|
0
|
0
|
1
|
0
|
|
CLERK
|
1
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
1
|
1
|
0
|
1
|
|
MANAGER
|
0
|
0
|
0
|
1
|
0
|
1
|
1
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
PRESIDENT
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
1
|
0
|
0
|
0
|
0
|
0
|
|
SALESMAN
|
0
|
1
|
1
|
0
|
1
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
表11.-6顯示了第8、10和13行的值為ANALYST，而第4、6和7行的值為MANAGER。在此還顯示了所有行都不為null（位圖索引可以存儲null條目；如果索引中沒有null條目，這說明表中沒有null行）。如果我們想統(tǒng)計值為MANAGER的行數(shù)，位圖索引就能很快地完成這個任務(wù)。如果我們想找出JOB為CLERK或MANAGER的所有行，只需根據(jù)索引合并它們的位圖，如表11.-7所示。
表 11.-7 位 OR 的表示
|
值/行
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
|
CLERK
|
1
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
1
|
1
|
0
|
1
|
|
MANAGER
|
0
|
0
|
0
|
1
|
0
|
1
|
1
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
CLERK或MANAGER
|
1
|
0
|
0
|
1
|
0
|
1
|
1
|
0
|
0
|
0
|
1
|
1
|
0
|
1
|
表11.-7清楚地顯示出，第1、4、6、7、11、12還有14行滿足我們的要求。Oracle如下為每個鍵值存儲位圖，使得每個位置表示底層表中的一個rowid，以后如果確實需要訪問行時，可以利用這個rowid進行處理。對于以下查詢：
select count(*) from emp where job = 'CLERK' or job = 'MANAGER；
用位圖索引就能直接得出答案。另一方面，對于以下查詢：
select * from emp where job = 'CLERK' or job = 'MANAGER'
則需要訪問表。在此 Oracle 會應(yīng)用一個函數(shù)把位圖中的第 i 位轉(zhuǎn)換為一個 rowid，從而可用于訪問表。
什么情況下應(yīng)該使用位圖索引？
位圖索引對于相異基數(shù)（distinctcard inality）低的數(shù)據(jù)最為合適（也就是說，與整個數(shù)據(jù)集的基數(shù)相比，這個數(shù)據(jù)只有很少幾個不同的值）。對此做出量化是不太可能的——換句話說，很難定義低相異基數(shù)到底是多大。在一個有幾千條記錄的數(shù)據(jù)集中，2就是一個低相異基數(shù)，但是在一個只有兩行的表中，2就不能算是低相異基數(shù)了。而在一個有上千萬或上億條記錄的表中，甚至100,000都能作為一個低相異基數(shù)。所以，多大才算是低相異基數(shù)，這要相對于結(jié)果集的大小來說。這是指，行集中不同項的個數(shù)除以行數(shù)應(yīng)該是一個很小的數(shù)（接近于0）。例如，GENDER列可能取值為M、F和NULL。如果一個表中有20,000條員工記錄，那么3/20000=0.00015。類似地，如果有100,000個不同的值，與11.,000,000條結(jié)果相比，比值為0.01，同樣這也很小（可算是低相異基數(shù)）。這些列就可以建立位圖索引。它們可能不適合建立B*樹索引，因為每個值可能會獲取表中的大量數(shù)據(jù)（占很大百分比）。如前所述，B*樹索引一般來講應(yīng)當是選擇性的。與之相反，位圖索引不應(yīng)是選擇性的，一般來講它們應(yīng)該“沒有選擇性“。
不過，在某些情況下，位圖并不合適。位圖索引在讀密集的環(huán)境中能很好地工作，但是對于寫密集的環(huán)境則極不適用。原因在于，一個位圖索引鍵條目指向多行。如果一個會話修改了所索引的數(shù)據(jù)，那么在大多數(shù)情況下，這個索引條目指向的所有行都會被鎖定。Oracle無法鎖定一個位圖索引條目中的單獨一位；而是會鎖定這個位圖索引條目。倘若其他修改也需要更新同樣的這個位圖索引條目，就會被“關(guān)在門外“。這樣將大大影響并發(fā)性，因為每個更新都有可能鎖定數(shù)百行，不允許并發(fā)地更新它們的位圖列。在此不是像你所想的那樣鎖定每一行，而是會鎖定很多行。位圖存儲在塊（chunk）中，所以，使用前面的EMP例子就可以看到，索引鍵ANALYST在索引中出現(xiàn)了多次，每一次都指向數(shù)百行。更新一行時，如果修改了JOB列，則需要獨占地訪問其中兩個索引鍵條目：對應(yīng)老值的索引鍵條目和對應(yīng)新值的索引鍵條目。這兩個條目指向的數(shù)百行就不允許其他會話修改，直到UPDATE提交。