Calvin's Tech Space

Oracle索引——位圖索引

位圖索引（bitmap index）是從Oracle7.3版本開始引入的。目前Oracle企業(yè)版和個(gè)人版都支持位圖索引，但標(biāo)準(zhǔn)版不支持。位圖索引是為數(shù)據(jù)倉庫/即席查詢環(huán)境設(shè)計(jì)的，在此所有查詢要求的數(shù)據(jù)在系統(tǒng)實(shí)現(xiàn)時(shí)根本不知道。位圖索引特別不適用于OLTP系統(tǒng)，如果系統(tǒng)中的數(shù)據(jù)會由多個(gè)并發(fā)會話頻繁地更新，這種系統(tǒng)也不適用位圖索引。

位圖索引是這樣一種結(jié)構(gòu)，其中用一個(gè)索引鍵條目存儲指向多行的指針；這與B*樹結(jié)構(gòu)不同，在B*樹結(jié)構(gòu)中，索引鍵和表中的行存在著對應(yīng)關(guān)系。在位圖索引中，可能只有很少的索引條目，每個(gè)索引條目指向多行。而在傳統(tǒng)的B*樹中，一個(gè)索引條目就指向一行。

下面假設(shè)我們要在 EMP 表的 JOB 列上創(chuàng)建一個(gè)位圖索引，如下：

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

Index created.

Oracle 在索引中存儲的內(nèi)容如表 11.-6 所示。

表 11.-6 Oracle 如何存儲 JOB-IDX 位圖索引

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

表 11.-7 位 OR 的表示

表11.-7清楚地顯示出，第1、4、6、7、11、12還有14行滿足我們的要求。Oracle如下為每個(gè)鍵值存儲位圖，使得每個(gè)位置表示底層表中的一個(gè)rowid，以后如果確實(shí)需要訪問行時(shí)，可以利用這個(gè)rowid進(jìn)行處理。對于以下查詢：

select count(*) from emp where job = 'CLERK' or job = 'MANAGER；

用位圖索引就能直接得出答案。另一方面，對于以下查詢：

select * from emp where job = 'CLERK' or job = 'MANAGER'

則需要訪問表。在此 Oracle 會應(yīng)用一個(gè)函數(shù)把位圖中的第 i 位轉(zhuǎn)換為一個(gè) rowid，從而可用于訪問表。

什么情況下應(yīng)該使用位圖索引？

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

不過，在某些情況下，位圖并不合適。位圖索引在讀密集的環(huán)境中能很好地工作，但是對于寫密集的環(huán)境則極不適用。原因在于，一個(gè)位圖索引鍵條目指向多行。如果一個(gè)會話修改了所索引的數(shù)據(jù)，那么在大多數(shù)情況下，這個(gè)索引條目指向的所有行都會被鎖定。Oracle無法鎖定一個(gè)位圖索引條目中的單獨(dú)一位；而是會鎖定這個(gè)位圖索引條目。倘若其他修改也需要更新同樣的這個(gè)位圖索引條目，就會被“關(guān)在門外“。這樣將大大影響并發(fā)性，因?yàn)槊總€(gè)更新都有可能鎖定數(shù)百行，不允許并發(fā)地更新它們的位圖列。在此不是像你所想的那樣鎖定每一行，而是會鎖定很多行。位圖存儲在塊（chunk）中，所以，使用前面的EMP例子就可以看到，索引鍵ANALYST在索引中出現(xiàn)了多次，每一次都指向數(shù)百行。更新一行時(shí)，如果修改了JOB列，則需要獨(dú)占地訪問其中兩個(gè)索引鍵條目：對應(yīng)老值的索引鍵條目和對應(yīng)新值的索引鍵條目。這兩個(gè)條目指向的數(shù)百行就不允許其他會話修改，直到UPDATE提交。