透過以下實驗，來驗證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”兩種。在這個基本原則的基礎上，要認真考慮包含點陣圖索引的表的操作特點，如果是併發操作高的系統，不適合使用點陣圖索引！

Good luck.

secooler
12.05.07

-- The End --

【Bitmap Index】B-Tree索引與Bitmap點陣圖索引的鎖代價比較研究

相關文章