sql-server

9 Пост

oracle

9 Пост

postgresql

12 Пост

my-sql

2 Пост

common-sql

2 Пост

News

5 Новости

Bitmap Index

A bitmap index is a specialized database index that represents indexed values using bitmaps—sequences of binary bits (0 and 1) rather than storing a separate row pointer for every occurrence of a value.

For each distinct value of the indexed column, the index maintains a bitmap. Each logical bit position corresponds to a row location in the indexed table:

 
1 = the row contains this indexed value
0 = the row does not contain this indexed value
 

Consider:

 
 
ROW STATUS
--- ---------
1 ACTIVE
2 INACTIVE
3 ACTIVE
4 PENDING
5 ACTIVE
6 INACTIVE
7 ACTIVE
8 PENDING
 

The logical bitmap representation is:

 
Row position
1 2 3 4 5 6 7 8
---------------
 
ACTIVE 1 0 1 0 1 0 1 0
INACTIVE 0 1 0 0 0 1 0 0
PENDING 0 0 0 1 0 0 0 1
 

For example:

 
ACTIVE = 10101010
 

means rows 1, 3, 5 and 7 contain ACTIVE.

This is fundamentally different from the conceptual representation of a traditional B-tree index:

 
B-tree
 
ACTIVE → ROWID 1
ACTIVE → ROWID 3
ACTIVE → ROWID 5
ACTIVE → ROWID 7
 

whereas a bitmap index can represent membership across a range of row locations using a bitmap:

 
 
Bitmap
 
ACTIVE → 1 0 1 0 1 0 1 0
 

This representation becomes especially useful when a column has relatively few distinct values compared with the number of rows, and when queries combine several conditions.

For example:

 
SELECT *
FROM sales
WHERE status = 'ACTIVE'
AND region = 'EUROPE';
If both columns are bitmap-indexed, Oracle can combine their bitmaps using a bitwise AND:
 
ACTIVE
 
1 0 1 1 1 0 1 0
 
EUROPE
 
1 1 0 1 0 0 1 0
 
AND
-----------------
1 0 0 1 0 0 1 0
 
The resulting bitmap immediately identifies the row positions satisfying both conditions.

But there is an important Oracle-specific detail behind this simplified explanation:

Oracle does not literally maintain one enormous uncompressed bitmap where bit #1 means "table row #1", bit #2 means "table row #2", and so on.

Oracle tables do not have permanent sequential row numbers. Rows are physically identified using ROWIDs. Oracle therefore stores bitmap information in index entries associated with ranges of ROWIDs, and the bitmap represents rows within those ranges.

That is where the real internal explanation should begin.

So the progression should be:

Definition → simple bitmap example → B-tree difference → bitwise operations → Oracle ROWID-based physical implementation → compression → execution plans → DML/locking → optimizer behavior.

That will give you the detailed description you asked for without making the beginning unnecessarily complicated.