【索引】Bitmap點陣圖索引與普通的B-Tree索引鎖的比較

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

1.為比較區別，建立兩種索引型別的測試表

1）在表t_bitmap上建立點陣圖索引

SYS@ORA11GR2>create table t_bitmap (id number (10),name varchar2(10),sex varchar2(1));

 

Table created.

 

SYS@ORA11GR2>create bitmap index t_bitmap_idx on t_bitmap(sex);

 

Index created.

 

2）在表t_btree上建立普通B-Tree索引

SYS@ORA11GR2>create table t_btree (id number(10),name varchar2(10),sex varchar2(1));

 

Table created.

 

SYS@ORA11GR2>create index t_btree_idx on t_btree(sex);

 

Index created.

 

2.每張表中初始化兩條資料

1）初始化資料t_bitmap表資料

SYS@ORA11GR2>insert into t_bitmap values(1,'WANG','M');

 

1 row created.

 

SYS@ORA11GR2>insert into t_bitmap values(2,'chen','F');

 

1 row created.

2）初始化資料t_btree表資料

SYS@ORA11GR2>insert into t_btree values(1,'WANG','M');

 

1 row created.

 

SYS@ORA11GR2>insert into t_btree values(2,'chen','F');

 

1 row created.

 

SYS@ORA11GR2>commit;

 

Commit complete.

 

3）檢視初始化之後的結果

SYS@ORA11GR2>select * from t_bitmap;

 

        ID NAME       S

---------- ---------- -

         1 WANG       M

         2 chen       F

 

SYS@ORA11GR2>select * from t_btree;

 

        ID NAME       S

---------- ---------- -

         1 WANG       M

         2 chen       F

 

3.在兩個不同的session中，對具有普通B-Tree索引表t_btree演示插入、修改和刪除“男孩”資料

——第一個session中的插入後不要提交

SYS@ORA11GR2>insert into t_btree values (3,'ANDY','M');

 

1 row created.

 

——第二個session中插入同樣的狀態資料，可以看到，插入、修改和刪除均能夠成功完成！

SYS@ORA11GR2>insert into t_btree values(4,'tut','M');

 

1 row created.

 

SYS@ORA11GR2>update t_btree set sex='M' where id=2;

 

1 row updated.

 

4.在兩個不同的session中，對具有Bitmap點陣圖索引表t_bitmap演示插入、修改和刪除“男孩”資料

1）第一個session中的插入後不要提交

SYS@ORA11GR2>insert into t_bitmap values(3,'ANDY','M');

 

1 row created.

 

2）第二個session中對男孩資料進行處理，可以看到，只要操作資訊中涉及到點陣圖索引列的插入、修改和刪除均無法完成！！

（1）插入測試
當插入資料涉及點陣圖索引列“sex”欄位時，是無法完成的。

SYS@ORA11GR2>insert into t_bitmap values(4,'tut','M');

問題出現了：出現了“鎖等待”停滯不動的現象！

 

當插入資料未涉及點陣圖索引列“sex”欄位時，是可以完成的。

SYS@ORA11GR2>insert into t_bitmap(id,name) values(4,'tut');

 

1 row created.

 

SYS@ORA11GR2>commit;

 

Commit complete.

 

（2）更新測試
此時第二個會話的測試資料內容如下：

當更新點陣圖索引列“sex”欄位值為“M”時，是無法完成的。此時成功，是因為第一行資料的sex值本身就是“M”。

SYS@ORA11GR2>update t_bitmap set sex='M' where id=1;

 

1 row updated.

 

SYS@ORA11GR2>update t_bitmap set sex='M' where id=2;

問題出現了：出現了“鎖等待”停滯不動的現象！

 

SYS@ORA11GR2>update t_bitmap set sex='M' where id=4；

問題出現了：出現了“鎖等待”停滯不動的現象！

 

另外，特別注意一下，如果更新的列不是點陣圖索引對應的列，將不會受點陣圖段級索引鎖的限制。如下所示。

SYS@ORA11GR2>update t_bitmap set name='xu' where id=2;

 

1 row updated.

 

SYS@ORA11GR2>select * from t_bitmap;

 

        ID NAME       S

---------- ---------- -

         1 WANG       M

         2 xu          F

         4 tut

 

（3）刪除測試

SYS@ORA11GR2>delete from t_bitmap where id=1;

出現了“鎖等待”停滯不動的現象！

SYS@ORA11GR2>delete from t_bitmap;

問題出現了：出現了“鎖等待”停滯不動的現象！

總結：

1.對於B-Tree索引來說，插入動作不影響其他會話的DML操作；但是，對於Bitmap索引來說，由於是索引段級鎖，會導致與操作列值相關的內容被鎖定（文中提到的“M”資訊）。

2.產生上面現象的原因：點陣圖索引被儲存為壓縮的索引值，其中包含了一個範圍內的ROWID，因此ORACLE必須針對一個給定值鎖定所有範圍內的ROWID，不支援行級別的鎖定。換一種描述方法：使用點陣圖索引時，一個鍵指向多行（成百上千），如果更新一個點陣圖索引鍵，會同時將其他行對應點陣圖索引欄位進行鎖定！
3.較之bitmap索引優點：點陣圖以一種壓縮格式存放，因此佔用的磁碟空間比B-Tree索引要小得多
4.較之bitmap索引缺點：這種鎖定的代價很高，會導致一些DML語句出現“鎖等待”，嚴重影響插入、更新和刪除的效率，對於高併發的系統不適用。
5.點陣圖索引使用原則： 點陣圖索引主要用於決策支援系統或靜態資料，不支援索引行級鎖定。
  點陣圖索引最好用於低cardinality列（即列的唯一值除以行數為一個很小的值，接近零），例如上面的“性別”列，列值有“M”，“F”兩種。在這個基本原則的基礎上，要認真考慮包含點陣圖索引的表的操作特點，如果是併發操作高的系統，不適合使用點陣圖索引！