A bitmap index is a special kind of index that represents the values of a column using bit vectors (bitmaps) instead of traditional key‑pointer pairs.
It is especially useful for low‑cardinality columns (columns with few distinct values), such as gender, status, or region, where each distinct value is mapped to a bit vector over all rows.
How a Bitmap Index Works
For a given column, a bitmap index creates one bit vector per distinct value:
Each bit in the vector corresponds to one row in the table.
A bit is 1 if the row has that value, and 0 otherwise.
For example, for a GENDER column with values M and F:
One bitmap for
Mwith bits = 1 where the row is male.One bitmap for
Fwith bits = 1 where the row is female.
To answer a query like WHERE gender = 'M', the DBMS simply scans the M bitmap and picks all rows where the bit is 1.
Using Bitmaps for Complex Queries
Bitmap indices become powerful for multi‑condition queries because logical operations on bit vectors are very fast:
AND of two bitmaps gives rows satisfying both conditions.
OR gives rows satisfying either condition.
NOT can be used to exclude rows.
For example:
WHERE gender = 'M' AND status = 'Active'
→ AND theMbitmap with theActivebitmap.
The result is a bitmask of qualifying rows, which the DBMS can then fetch or further combine with other conditions.
When to Use Bitmap Indexes
Bitmap indexes are best suited for:
Low‑cardinality columns (few distinct values).
Read‑heavy workloads, such as data warehouses and OLAP systems.
Queries with multiple filters that combine with
AND/OR.
They are not ideal for:
High‑cardinality columns (too many bitmaps).
Very frequently updated tables (bitmaps are expensive to modify).
For beginners, a bitmap index is like a compact grid of switches: each row is a column in the grid, each value is a row of switches, and “switch on” means that row has that value. The DBMS just flips bits and combines grids to answer complex queries quickly.
Summary
A bitmap index in DBMS uses bit vectors to represent column values, making it extremely efficient for low‑cardinality columns and complex filter conditions. It excels in read‑intensive environments where queries combine multiple predicates, but it is less suitable for highly updated tables or columns with many distinct values.