Oracle Bitmap Index 使用注意点

Bitmap index: 使用场景是针对那些 值不经常改变的 并且NDV（number of distinct values）较低的字段

如果某个字段频繁更新，例如Flag 字段，是不适合创建bitmap索引的。 应为锁使用机制，位图索引只允许一个用户操作，只有的该会话COMMIT or ROLLBACK 后 第二个会话才能获得锁。 在并发是情况下，这就会限制数据库的性能。

 

If a session is waiting due to a shared bitmap index fragment. Bitmap indexes index key values and a range of rowids. Each entry in a bitmap index can cover many rows in the actual table. If two sessions want to update rows covered by the same bitmap index fragment, then the second session waits for the first transaction to either COMMIT or ROLLBACK by waiting for the TX lock.

 

Oralce doc：

In a conventional B-tree index, one index entry points to a single row. In a bitmap index, the key is the combination of the indexed data and the rowid range.

The database stores at least one bitmap for each index key. Each value in the bitmap, which is a series of 1 and 0 values, points to a row within a rowid range. Thus, in a bitmap index, one index entry points to a set of rows rather than a single row.

This section contains the following topics:

• Differences Between Bitmap and B-Tree Indexes
  A bitmap index uses a different key from a B-tree index, but is stored in a B-tree structure.
• Purpose of Bitmap Indexes
  Bitmap indexes are typically suitable for infrequently modified data with a low or medium number of distinct values (NDV).
• Bitmaps and Rowids
  For a particular value in a bitmap, the value is 1 if the row values match the bitmap condition, and 0 if it does not. Based on these values, the database uses an internal algorithm to map bitmaps onto rowids.
• Bitmap Join Indexes
  A bitmap join index is a bitmap index for the join of two or more tables.
• Bitmap Storage
  A bitmap index resides in a B-tree structure, using branch blocks and leaf blocks just as in a B-tree.

A bitmap index uses a different key from a B-tree index, but is stored in a B-tree structure.

The following table shows the differences among types of index entries.

Table 8-3 Index Entries for B-Trees and Bitmaps

Index Entry	Key	Data	Example
Unique B-tree	Indexed data only	Rowid	In an entry of the index on the employees.employee_idcolumn, employee ID 101 is the key, and the rowid AAAPvCAAFAAAAFaAAa is the data: 101,AAAPvCAAFAAAAFaAAa
Nonunique B-tree	Indexed data combined with rowid	None	In an entry of the index on the employees.last_namecolumn, the name and rowid combination Smith,AAAPvCAAFAAAAFaAAa is the key, and there is no data: Smith,AAAPvCAAFAAAAFaAAa
Bitmap	Indexed data combined with rowid range	Bitmap	In an entry of the index on the customers.cust_gendercolumn, the M,low-rowid,high-rowid part is the key, and the series of 1 and 0 values is the data: M,low-rowid,high-rowid,1000101010101010

The database stores a bitmap index in a B-tree structure. The database can search the B-tree quickly on the first part of the key, which is the set of attributes on which the index is defined, and then obtain the corresponding rowid range and bitmap.

 

8.4.1.2 Purpose of Bitmap Indexes

Bitmap indexes are typically suitable for infrequently modified data with a low or medium number of distinct values (NDV).

In general, B-tree indexes are suitable for columns with high NDV and frequent DML activity. For example, the optimizer might choose a B-tree index for a query of a sales.amount column that returns few rows. In contrast, the customers.state and customers.county columns are candidates for bitmap indexes because they have few distinct values, are infrequently updated, and can benefit from efficient AND and OR operations.

Bitmap indexes are a useful way to speed ad hoc queries in a data warehouse. They are fundamental to star transformations. Specifically, bitmap indexes are useful in queries that contain the following:

• Multiple conditions in the WHERE clause

  Before the table itself is accessed, the database filters out rows that satisfy some, but not all, conditions.

• AND, OR, and NOT operations on columns with low or medium NDV

  Combining bitmap indexes makes these operations more efficient. The database can merge bitmaps from bitmap indexes very quickly. For example, if bitmap indexes exist on the customers.state and customers.county columns, then these indexes can enormously improve the performance of the following query:

  SELECT * 
  FROM   customers 
  WHERE  state = 'CA' 
  AND    county = 'San Mateo'

  The database can convert 1 values in the merged bitmap into rowids efficiently.

• The COUNT function

  The database can scan the bitmap index without needing to scan the table.

• Predicates that select for null values

  Unlike B-tree indexes, bitmap indexes can contain nulls. Queries that count the number of nulls in a column can use the bitmap index without scanning the table.

• Columns that do not experience heavy DML

  The reason is that one index key points to many rows. If a session modifies the indexed data, then the database cannot lock a single bit in the bitmap: rather, the database locks the entire index entry, which in practice locks the rows pointed to by the bitmap. For example, if the county of residence for a specific customer changes from San Mateo to Alameda, then the database must get exclusive access to the San Mateo index entry and Alameda index entry in the bitmap. Rows containing these two values cannot be modified until COMMIT.

BITMAP:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/tgsql/optimizer-access-paths.html#GUID-0604FCDA-473B-432F-B1B2-8F766D377D63

LOCK

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/refrn/descriptions-of-wait-events.html#GUID-349A3385-B004-4D75-9B58-E4FFE62A57EB