通過以下實驗，來驗證Bitmap位圖索引較之普通的B-Tree索引鎖的“高昂代價”。位圖索引會帶來“位圖段級鎖”，實際使用過程一定要充分了解不同索引帶來的鎖代價情況。

1.為比較區別，創建兩種索引類型的測試表
1）在表t_bitmap上創建位圖索引
SEC@ora11g> create table t_bitmap (id number(10), name varchar2(10),sex varchar2(1));

Table created.

SEC@ora11g> create bitmap index t_bitmap_idx on t_bitmap(sex);

Index created.

2）在表t_btree上創建普通B-Tree索引
SEC@ora11g> create table t_btree (id number(10), name varchar2(10), sex varchar2(1));

Table created.

SEC@ora11g> create index t_btree_idx on t_btree(sex);

Index created.

2.每張表中初始化兩條數據：“一個男孩”和“一個女孩”
注釋：
M - Male - 表示男孩；
F - Femail - 表示女孩。

1）初始化數據t_btree表數據
SEC@ora11g> insert into t_btree values (1, 'Secoooler', 'M');

1 row created.

SEC@ora11g> insert into t_btree values (2, 'Anna','F');

1 row created.

2）初始化數據t_bitmap表數據
SEC@ora11g> insert into t_bitmap values (1, 'Secoooler', 'M');

1 row created.

SEC@ora11g> insert into t_bitmap values (2, 'Anna','F');

1 row created.

SEC@ora11g> commit;

Commit complete.

3）查看初始化之后的結果
（1）t_btree表中包含兩條數據
SEC@ora11g> select * from t_btree;

??????? ID NAME?????? S
---------- ---------- -
???????? 1 Secoooler? M
???????? 2 Anna?????? F

（2）t_bitmap表中包含兩條數據
SEC@ora11g> select * from t_bitmap;

??????? ID NAME?????? S
---------- ---------- -
???????? 1 Secoooler? M
???????? 2 Anna?????? F

3.在兩個不同的session中，對具有普通B-Tree索引表t_btree演示插入、修改和刪除“男孩”數據
第一個session中的插入后不要提交
SEC@ora11g> insert into t_btree values (3, 'Andy', 'M');

1 row created.

第二個session中插入同樣的狀態數據，可以看到，插入、修改和刪除均能夠成功完成
SEC@ora11g> insert into t_btree values (4, 'Tutu', 'M');

1 row created.

SEC@ora11g> update t_btree set sex='M' where id=2;

1 row updated.

SEC@ora11g> delete from t_btree;

2 rows deleted.

4.在兩個不同的session中，對具有Bitmap位圖索引表t_bitmap演示插入、修改和刪除“男孩”數據
1）第一個session中的插入后不要提交
SEC@ora11g> insert into t_bitmap values (3, 'Andy', 'M');

1 row created.

2）第二個session中對男孩數據進行處理，可以看到，只要操作信息中涉及到位圖索引列的插入、修改和刪除均無法完成！！
（1）插入測試
當插入數據涉及位圖索引列“sex”字段時，是無法完成的。
SEC@ora11g> insert into t_bitmap values (4, 'Tutu', 'M');
問題出現了：出現了“鎖等待”停滯不動的現象！

當插入數據未涉及位圖索引列“sex”字段時，是可以完成的。
SEC@ora11g> insert into t_bitmap(id,name) values (4, 'Tutu');

1 row created.

SEC@ora11g> commit;

Commit complete.

（2）更新測試
此時第二個會話的測試數據內容如下。
SEC@ora11g> select * from t_bitmap;

??????? ID NAME?????? S
---------- ---------- -
???????? 1 Secoooler? M
???????? 2 Anna?????? F
???????? 4 Tutu

當更新位圖索引列“sex”字段值為“M”時，是無法完成的。
SEC@ora11g> update t_bitmap set sex='M' where id=1;

1 row updated.

此時成功，是因為第一行數據的sex值本身就是“M”。

SEC@ora11g> update t_bitmap set sex='M' where id=2;
問題出現了：出現了“鎖等待”停滯不動的現象！

SEC@ora11g> update t_bitmap set sex='M' where id=4;
問題出現了：出現了“鎖等待”停滯不動的現象！

另外，特別注意一下，如果更新的列不是位圖索引對應的列，將不會受位圖段級索引鎖的限制。如下所示。
SEC@ora11g> update t_bitmap set name='Xu' where id=2;

1 row updated.

（3）刪除測試
當刪除的數據包含位圖索引列“sex”字段值為“M”時，是無法完成的。
SEC@ora11g> delete from t_bitmap where id=1;
問題出現了：出現了“鎖等待”停滯不動的現象！
當刪除表中的所有數據時，同樣的道理，也是不能刪除的。
SEC@ora11g> delete from t_bitmap;
問題出現了：出現了“鎖等待”停滯不動的現象！

5.小結
? 本文以對數據本身沖擊力最小的插入動作為例，演示了B-Tree和Bitmap索引的鎖代價。對于B-Tree索引來說，插入動作不影響其他會話的DML操作；但是，對于Bitmap索引來說，由于是索引段級鎖，會導致與操作列值相關的內容被鎖定（文中提到的“M”信息）。進一步，對于更新動作來說，

? 產生上面現象的原因：
? 位圖索引被存儲為壓縮的索引值，其中包含了一個范圍內的ROWID，因此ORACLE必須針對一個給定值鎖定所有范圍內的ROWID，不支持行級別的鎖定。
? 換一種描述方法：使用位圖索引時，一個鍵指向多行（成百上千），如果更新一個位圖索引鍵，會同時將其他行對應位圖索引字段進行鎖定！

? 較之B-Tree索引優點：
? 位圖以一種壓縮格式存放，因此占用的磁盤空間比B-Tree索引要小得多

? 較之B-Tree索引缺點：
? 這種鎖定的代價很高，會導致一些DML語句出現“鎖等待”，嚴重影響插入、更新和刪除的效率，對于高并發的系統不適用。

? 位圖索引使用原則：
? 位圖索引主要用于決策支持系統或靜態數據，不支持索引行級鎖定。
? 位圖索引最好用于低cardinality列（即列的唯一值除以行數為一個很小的值，接近零），例如上面的“性別”列，列值有“M”，“F”兩種。在這個基本原則的基礎上，要認真考慮包含位圖索引的表的操作特點，如果是并發操作高的系統，不適合使用位圖索引！

轉：http://blog.itpub.net/519536/viewspace-611296/

轉載于:https://www.cnblogs.com/andy6/p/5766934.html

總結

以上是生活随笔為你收集整理的【Bitmap Index】B-Tree索引与Bitmap位图索引的锁代价比较研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。