資料庫使用-oracle位元影像索引，-oracle位元影像索引

資料庫使用-oracle位元影像索引，-oracle位元影像索引

我們目前大量使用的索引一般主要是B*Tree索引，在索引結構中儲存著鍵值和鍵值的RowID,並且是一一對應的。而位元影像索引主要針對大量相同值的列而建立(例如：類別，操作員，部門ID,庫房ID等),索引塊的一個索引行中儲存鍵值和起止Rowid,以及這些鍵值的位置編碼,位置編碼中的每一位表示鍵值對應的資料行的有無.一個塊可能指向的是幾十甚至成百上千行資料的位置。這種方式儲存資料,相對於B*Tree索引,佔用的空間非常小,建立和使用非常快。

        位元影像索引的目標是為使用者提供指向包含特定鍵值（key value）的資料行的指標。在常規的索引中，Oracle將各行的鍵值及與此鍵值對應的一組 ROWID儲存在一起，從而實現了上述目標。而在位元影像索引（bitmap index）中，只需儲存每個鍵值的位元影像（bitmap），而非一組 ROWID。

        位元影像（bitmap）中的每一位（bit）對應一個可能的 ROWID。如果某一位被置位（set），則表明著與此位對應的 ROWID所指向的行中包含此位所代表的鍵值（key value）。Oracle通過一個映射函數（mapping function）將位資訊轉化為實際的 ROWID，因此雖然位元影像索引（bitmap index）內部的儲存結構與常規索引不同，但她同樣能實現常規索引的功能。當不同值的索引鍵的數量較少時，位元影像索引的儲存效率相當高。

        如果在 WHERE 子句內引用的多個列上都建有位元影像索引（bitmap index），那麼進行位元影像索引掃描時（bitmap indexing）可以將各個位元影像索引融合在一起。不滿足全部條件的行可以被預先過濾掉。因此使用位元影像索引能夠極大地提高查詢的回應時間。

資料倉儲應用中位元影像索引的優勢

        資料倉儲應用（data warehousingapplication）的特點是資料量巨大，執行的多為自訂查詢（ad hoc query），且並發事務較少。這種環境下使用位元影像索引（bitmap index）具備如下優勢：

·        能夠減少大資料量自訂查詢的回應時間

·        與其他索引技術相比能夠節省大量儲存空間

·        即使硬體設定較低也能顯著提高效能

·        有利於並行 DML和並行載入

        為一個大表建立傳統的平衡樹索引（B-tree index）可能佔用極大的儲存空間，索引有可能比資料表還要大數倍。而一個位元影像索引（bitmap index）所佔的空間比被索引資料還要小得多。

        位元影像索引（bitmap index）不適用於 OLTP系統，因為這樣的系統中存在大量對資料進行修改的並發事務。位元影像索引主要用於資料倉儲系統中（data warehousing）的決策支援功能，在這種環境下使用者對資料的操作主要是查詢而非修改。

        主要進行大於（greater than）或小於（less than）比較的列，不適宜使用位元影像索引（bitmap index）。例如，WHERE 子句中常會將 salary列和一個值進行比較，此時更適合使用平衡樹索引（B-tree index）。位元影像索引適用於等值查詢，尤其是存在 AND，OR，和 NOT 等邏輯操作符的組合時。

        位元影像索引（bitmap index）是整合在 Oracle的最佳化器（optimizer）和執行引擎（execution engine）之中的。位元影像索引也能夠和 Oracle 中的其他執行方法（execution method）無縫地組合。例如，最佳化器可以在利用一個表的位元影像索引和另一個表的平衡樹索引（B-tree index）對這兩張表進行雜湊串連（hash join）。最佳化器能夠在位元影像索引及其他可用的存取方法（例如常規的平衡樹索引，或全表掃描（full table scan））中選擇效率最高的方式，同時考慮是否適合使用並存執行。

        位元影像索引（bitmap index）如同常規索引一樣，可以結合并行查詢（parallel query）和並行 DML（parallel DML）一起工作。建立於分區表（partitioned table）的位元影像索引必須為本地索引（local index）。Oracle還支援並行地建立位元影像索引，以及建立複合位元影像索引。

基數

        在基數（cardinality）小的列上建立位元影像索引（bitmap index）效果最好。所謂某列的基數小（low cardinality）是指此列中所有不相同的值的個數要小於總行數。如果某列中所有不相同的值的個數佔總行數的比例小於 1%，或某列中值的重複數量在 100個以上，那麼就可以考慮在此列上建立位元影像索引。即便某列的基數較上述標準稍大，或值的重複數量較上述標準稍小，如果在一個查詢的 WHERE 子句中需要引用此列定義複雜的條件，也可以考慮在此列上建立位元影像索引。

        例如，一個表包含一百萬行資料，其中的一列包含一萬個不相同的值，就可以考慮在此列上建立位元影像索引（bitmap index）。此列上位元影像索引的查詢效能將超過平衡樹索引（B-tree index），當此列與其他列作為組合條件時效果尤為明顯。

        平衡樹索引（B-tree index）適用於高基數的資料，即資料的可能值很多，例如CUSTOMER_NAME 或 PHONE_NUMBER 列。在有些情況下，平衡樹索引所需的儲存空間可能比被索引資料還要大。如果使用得當，位元影像索引將遠遠小於同等情況下的平衡樹索引。

        對於自訂查詢（ad hoc query）或相似的應用，使用位元影像索引（bitmap index）能夠顯著地提高查詢效能。查詢的 WHERE 子句中的 AND 和 OR 條件直接對位元影像（bitmap）進行布爾運算（Boolean operation）得到一個位元影像結果集（resulting bitmap），而無需將所有的位元影像轉換為 ROWID。如果布爾操作後的結果集較小，那麼查詢就能夠迅速得到結果，而無需進行全表掃描（full table scan）。

位元影像索引和空值

        與其他大多數索引不同，位元影像索引（bitmap index）可以包含鍵值（key value）為 NULL 的行。將鍵值為空白的行進行索引對有些 SQL語句是有用處的，例如包含 COUNT 彙總函式的查詢。

分區表上的位元影像索引

        使用者可以在分區表（partitioned table）上建立位元影像索引（bitmap index）。唯一的限制是位元影像索引對分區表來說必須是本地的（local），而不能是全域索引（global index）。只有非分區表才能使用全域位元影像索引。                                                                              

位元影像串連索引

        除了建立在單個表之上的位元影像索引（bitmap index），使用者還可以建立位元影像串連索引（bitmap join index），此種索引是為了串連（join）兩個或多個資料表而建的。位元影像串連索引（bitmap join index）可以預先將有串連關係的資料進行儲存，且所需的儲存空間較小。對於一個表的某列的每個值，位元影像串連索引為其儲存其他表中與此值有串連關係的資料行的 rowid。在資料倉儲環境中，串連關係通常是維表（dimension table）中的主鍵（primary key）與事實表（fact table）中的外鍵（foreign key）進行等值內串連（equi-inner join）。

        物化串連視圖（materialized joinview）也是一種預先將串連物化的方法，但與之相比位元影像串連索引（bitmap join index）所需的儲存空間更少。因為物化串連視圖不會壓縮事實表（fact table）中的 rowid。

 

位元影像索引的優缺點

優點：OLAP例如報表類資料庫重複率高的資料特定類型的查詢例如count、or、and等邏輯操作因為只需要進行位元運算即可得到我們需要的結果

缺點：不適合重複率低的欄位，還有經常DML操作（insert，update，delete），因為位元影像索引的鎖代價極高，修改一個位元影像索引段影響整個位元影像段，例如修改

一個鍵值，會影響同鍵值的多行，所以對於OLTP系統位元影像索引可能不是最合適的，甚至是會對系統系統造成嚴重危害的；（BDC平台，主入口表的狀態嘗試修改為位元影像索引，導致當時入庫資料堵塞嚴重）。

總而言之，在平台中如果要使用位元影像索引，一定要仔細驗證使用前後的效能情況。

 

有部分文字和內容來自互連網