Oracle索引——點陣圖索引

Oracle索引——點陣圖索引

點陣圖索引（bitmap index）是從Oracle7.3版本開始引入的。目前Oracle企業版和個人版都支援點陣圖索引，但標準版不支援。點陣圖索引是為資料倉儲/即席查詢環境設計的，在此所有查詢要求的資料在系統實現時根本不知道。點陣圖索引特別不適用於OLTP系統，如果系統中的資料會由多個併發會話頻繁地更新，這種系統也不適用點陣圖索引。

點陣圖索引是這樣一種結構，其中用一個索引鍵條目儲存指向多行的指標；這與B*樹結構不同，在B*樹結構中，索引鍵和表中的行存在著對應關係。在點陣圖索引中，可能只有很少的索引條目，每個索引條目指向多行。而在傳統的B*樹中，一個索引條目就指向一行。

下面假設我們要在 EMP 表的 JOB 列上建立一個點陣圖索引，如下：

Ops$tkyte@ORA10G> create BITMAP index job_idx on emp(job);

Index created.

Oracle 在索引中儲存的內容如表 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行）。如果我們想統計值為MANAGER的行數，點陣圖索引就能很快地完成這個任務。如果我們想找出JOB為CLERK或MANAGER的所有行，只需根據索引合併它們的點陣圖，如表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 會應用一個函式把點陣圖中的第 i 位轉換為一個 rowid，從而可用於訪問表。

什麼情況下應該使用點陣圖索引？

點陣圖索引對於相異基數（distinctcard inality）低的資料最為合適（也就是說，與整個資料集的基數相比，這個資料只有很少幾個不同的值）。對此做出量化是不太可能的——換句話說，很難定義低相異基數到底是多大。在一個有幾千條記錄的資料集中，2就是一個低相異基數，但是在一個只有兩行的表中，2就不能算是低相異基數了。而在一個有上千萬或上億條記錄的表中，甚至100,000都能作為一個低相異基數。所以，多大才算是低相異基數，這要相對於結果集的大小來說。這是指，行集中不同項的個數除以行數應該是一個很小的數（接近於0）。例如，GENDER列可能取值為M、F和NULL。如果一個表中有20,000條員工記錄，那麼3/20000=0.00015。類似地，如果有100,000個不同的值，與11.,000,000條結果相比，比值為0.01，同樣這也很小（可算是低相異基數）。這些列就可以建立點陣圖索引。它們可能不適合建立B*樹索引，因為每個值可能會獲取表中的大量資料（佔很大百分比）。如前所述，B*樹索引一般來講應當是選擇性的。與之相反，點陣圖索引不應是選擇性的，一般來講它們應該“沒有選擇性“。

不過，在某些情況下，點陣圖並不合適。點陣圖索引在讀密集的環境中能很好地工作，但是對於寫密集的環境則極不適用。原因在於，一個點陣圖索引鍵條目指向多行。如果一個會話修改了所索引的資料，那麼在大多數情況下，這個索引條目指向的所有行都會被鎖定。Oracle無法鎖定一個點陣圖索引條目中的單獨一位；而是會鎖定這個點陣圖索引條目。倘若其他修改也需要更新同樣的這個點陣圖索引條目，就會被“關在門外“。這樣將大大影響併發性，因為每個更新都有可能鎖定數百行，不允許併發地更新它們的點陣圖列。在此不是像你所想的那樣鎖定每一行，而是會鎖定很多行。點陣圖儲存在塊（chunk）中，所以，使用前面的EMP例子就可以看到，索引鍵ANALYST在索引中出現了多次，每一次都指向數百行。更新一行時，如果修改了JOB列，則需要獨佔地訪問其中兩個索引鍵條目：對應老值的索引鍵條目和對應新值的索引鍵條目。這兩個條目指向的數百行就不允許其他會話修改，直到UPDATE提交。