Calvin's Tech Space

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 位圖索引

表11.-6顯示了第8、10和13行的值為ANALYST，而第4、6和7行的值為MANAGER。在此還顯示了所有行都不為null（位圖索引可以存儲null條目；如果索引中沒有null條目，這說明表中沒有null行）。如果我們想統計值為MANAGER的行數，位圖索引就能很快地完成這個任務。如果我們想找出JOB為CLERK或MANAGER的所有行，只需根據索引合并它們的位圖，如表11.-7所示。

表 11.-7 位 OR 的表示

表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提交。