网站备案 快递,网站的建设项目是什么,电销crm管理系统,高质量外链网站位图(bitmap)索引是另外一种索引类型#xff0c;它的组织形式与B树索引相同#xff0c;也是一棵平衡树。与B树索引的区别在于叶子节点里存放索引条目的方式不同。从前面我们知道#xff0c;B树索引的叶子节点里#xff0c;对于表里的每个数据行#xff0c;如果被索引列的值…位图(bitmap)索引是另外一种索引类型它的组织形式与B树索引相同也是一棵平衡树。与B树索引的区别在于叶子节点里存放索引条目的方式不同。从前面我们知道B树索引的叶子节点里对于表里的每个数据行如果被索引列的值不为空的则会为该记录行在叶子节点里维护一个对应的索引条目。而位图索引则不是这样其叶子节点里存放的索引条目如下图所示。假设某个表T里所有的记录在列C1上只具有三个值01、02和03。在表T的C1列上创建位图索引以后则叶子节点的内容如图9-14所示。可以看到位图索引只有三个索引条目也就是每个C1列的值对应一个索引条目。位图索引条目上还包含表里第一条记录所对应的ROWID以及最后一条记录所对应的ROWID。索引条目的最后一部分则是由多个bit位所组成的bitmap每个bit位就对应一条记录。图1.JPG (28.68 KB, 下载次数: 12)2008-6-10 16:37 上传位图索引的结构当发出where c101这样的SQL语句时oracle会去搜索01所在的索引条目然后扫描该索引条目中的bitmap里所有的bit位。第一个bit位为1则说明第一条记录上的C1值为01于是返回第一条记录所在的ROWID(根据该索引条目里记录的start ROWID加上行号得到该记录所在的ROWID)。第二个bit位为0则说明第二条记录上的C1值不为01依此类推。另外如果索引列为空也会在位图索引里记录也就是将对应的bit位设置为0即可。如果索引列上不同值的个数比较少的时候比如对于性别列(男或女)等则使用位图索引会比较好因为它对空间的占用非常少(因为都是用bit位来表示表里的数据行)从而在扫描索引的时候扫描的索引块的个数也比较少。可以试想一下如果在列的不同值非常多的列上比如主键列上创建位图索引则产生的索引条目就等于表里记录的条数同时每个索引条目里的bitmap里只有一个1其它都是0。这样还不如B树索引的效率高。如果被索引的列经常被更新的话则不适合使用位图索引。因为当更新位图所在的列时由于要在不同的索引条目之间修改bit位比如将第一条记录从01变为02则必须将01所在的索引条目的第一个bit位改为0再将02所在的索引条目的第一个bit位改为1。因此在更新索引条目的过程中会锁定位图索引里多个索引条目。也就是同时只能有一个用户能够更新表T从而降低了并发性。位图索引比较适合用在数据仓库系统里不适合用在OLTP系统里。[php]SQL create table t_bitmap_test as2 select rownum as id,trunc(dbms_random.value(1,4)) as bitcol3 from dba_objects where rownum20;SQL select * from t_bitmap_test;ID BITCOL---------- ----------1 32 23 14 35 36 17 18 29 310 211 312 113 114 315 216 217 318 219 120 3SQL connect hr/hr已连接。SQL alter session set events 10608 trace name context forever, level 10;会话已更改。SQL create bitmap index idx_t_bitmap_test on t_bitmap_test(bitcol);索引已创建。SQL alter session set events 10608 trace name context off;会话已更改。SQL select object_id from user_objects where object_nameIDX_T_BITMAP_TEST;OBJECT_ID----------24499SQL alter session set events immediate trace name TREEDUMP level 24499;会话已更改。_______________[/php]10608事件用来跟踪创建bitmap索引的过程。而TREEDUMP则用来转储索引的树状结构。打开转储出来的文件*** SESSION ID7.13) 2008-06-10 14:33:46.000qerbiARwo: bitmap size is 8168qerbiIPI default pctfree10qerbiIPI length0qerbiAllocate pfree127 space8168qerbiStart first startqerbiRop: rid00c01ce4.0000, newY , key: (2): c1 04qerbiCmpSz notfound pctfree10qerbiCmpSz adjblksize7351 length0qerbiRop keysize4 maxbm3531kdibcoinit(3116714): srid00c01ce4.0000qerbiRop: rid00c01ce4.0001, newY , key: (2): c1 03kdibcoinit(3116698): srid00c01ce4.0001qerbiRop: rid00c01ce4.0002, newY , key: (2): c1 02kdibcoinit(311661c): srid00c01ce4.0002qerbiRop: rid00c01ce4.0003, newN, key: (2): c1 04qerbiRop: rid00c01ce4.0004, newN, key: (2): c1 04qerbiRop: rid00c01ce4.0005, newN, key: (2): c1 02qerbiRop: rid00c01ce4.0006, newN, key: (2): c1 02qerbiRop: rid00c01ce4.0007, newN, key: (2): c1 03qerbiRop: rid00c01ce4.0008, newN, key: (2): c1 04qerbiRop: rid00c01ce4.0009, newN, key: (2): c1 03qerbiRop: rid00c01ce4.000a, newN, key: (2): c1 04qerbiRop: rid00c01ce4.000b, newN, key: (2): c1 02qerbiRop: rid00c01ce4.000c, newN, key: (2): c1 02qerbiRop: rid00c01ce4.000d, newN, key: (2): c1 04qerbiRop: rid00c01ce4.000e, newN, key: (2): c1 03qerbiRop: rid00c01ce4.000f, newN, key: (2): c1 03qerbiRop: rid00c01ce4.0010, newN, key: (2): c1 04qerbiRop: rid00c01ce4.0011, newN, key: (2): c1 03qerbiRop: rid00c01ce4.0012, newN, key: (2): c1 02qerbiRop: rid00c01ce4.0013, newN, key: (2): c1 04kdibcoend(3116714): erid00c01ce4.0017status3qerbiCon: key: (2): c1 04srid00c01ce4.0 erid00c01ce4.17 bitmap: (4): ca 19 25 09kdibcoend(3116698): erid00c01ce4.0017status3qerbiCon: key: (2): c1 03srid00c01ce4.0 erid00c01ce4.17 bitmap: (4): ca 82 c2 02kdibcoend(311661c): erid00c01ce4.0017status3qerbiCon: key: (2): c1 02srid00c01ce4.0 erid00c01ce4.17 bitmap: (4): ca 64 18 04这一段是创建bitmap索引的过程。我们先把被索引的列的值换算成十六进制[php]SQL select dump(3),dump(2),dump(1) from dual;DUMP(3) DUMP(2) DUMP(1)------------------ ------------------ ------------------Typ2 Len2: 193,4 Typ2 Len2: 193,3 Typ2 Len2: 193,2_______________[/php]4、3、2对应的十六进制则是04、03、02。也就是上面转储部分显示的key部分的键值。可以看到oracle在创建bitmap索引时先从第一条记录开始扫描取出第一条记录的键值(bitcol3)也就是“qerbiRop: rid00c01ce4.0000, newY , key: (2): c1 04”。newY说明这是一个新的键值因此会对应到一个索引条目。扫描第二条记录时发现bitcol2该键值也是一个新的键值因此产生一个新的索引条目对应“qerbiRop: rid00c01ce4.0001, newY , key: (2): c1 03”。扫描到第三条记录时发现bitcol1该键值也是一个新的键值因此产生第三个索引条目对应“qerbiRop: rid00c01ce4.0002, newY , key: (2): c1 02”。接下来扫描到的记录所对应的bitcol的值都是1、2、3中的一个因此都不会产生新的索引条目因此它们的new都为N。然后扫描完表里的所有记录以后开始创建bitmap索引条目也就是下面的部分qerbiCon: key: (2): c1 04srid00c01ce4.0 erid00c01ce4.17 bitmap: (4): ca 19 25 09kdibcoend(3116698): erid00c01ce4.0017status3qerbiCon: key: (2): c1 03srid00c01ce4.0 erid00c01ce4.17 bitmap: (4): ca 82 c2 02kdibcoend(311661c): erid00c01ce4.0017status3qerbiCon: key: (2): c1 02srid00c01ce4.0 erid00c01ce4.17 bitmap: (4): ca 64 18 04这里的srid表示start rowiderid表示end rowid。可以看到总共产生了3个索引条目其key分别为04、03、02。这3个索引条目的start rowid和end rowid的格式分两部分中间用点隔开点左边的表示文件号(从左边第一个字节开始的4个字节表示)和数据块号(从左边第五个字节开始的4个字节表示)点右边表示数据块里的行号。这里的显示可以看到这20条记录都位于相同的数据块里。这里的00c0表示文件号[php]SQL select sys.pkg_number_trans.f_hex_to_dec(c)/4 file# FROM dual;FILE#----------3SQL select sys.pkg_number_trans.f_hex_to_dec(1ce4) as blk# FROM dual;BLK#----------------------7396_______________[/php]因此这20条记录在3号数据文件的7396号数据块里。我们可以使用dbms_rowid来验证。[php]SQL select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,2 dbms_rowid.rowid_block_number(rowid) as block#3 from t_bitmap_test;FILE# BLOCK#---------- ----------3 7396_______________[/php]可以看到完全符合。每个索引条目的“bitmap : (4)”部分表示的也就是前面说到的bit位了由1、0组成。按照前面bitmap的理论这20条记录所对应的三个索引条目的bitmap的样子应该为[php]Key_value start_rowid end_rowid 理论上的bitmap 转储文件的bitmap1 00c01ce4.0 00c01ce4.0017 00100110000110000010 ca 64 18 042 00c01ce4.0 00c01ce4.0017 01000001010000110100 ca 82 c2 023 00c01ce4.0 00c01ce4.0017 10011000101001001001 ca 19 25 09_______________[/php]转储文件里的bitmap如何对应到bit位呢 首先第一个字节的ca可以不考虑暂时不知道第一个字节是什么意思。只考虑后三个字节。比如对于key_value3来说192509对应的二进制为[php]SQL col c1 format a10SQL col c2 format a10SQL col c3 format a10SQL select sys.pkg_number_trans.f_hex_to_bin(19) as c1,2 sys.pkg_number_trans.f_hex_to_bin(25) as c2,3 sys.pkg_number_trans.f_hex_to_bin(09) as c3 from dual;C1 C2 C3---------- ---------- ----------11001 100101 1001_______________[/php]其中不足8位的前面用0补齐因此C100011001C200100101C300001001在二进制里每个应该倒过来从右到左排列因此为[php]C3 C2 C100001001 00100101 00011001_______________[/php]然后将它们组织为一个由多个bit位组成的bitmap的话仍然从右到左依次取出每个bit位于是我们有100110001010010010010000。我们可以把这个bit串与理论上的bitmap比较一下10011000101001001001000010011000101001001001很明显除了最后多出来的4个0以外其余部分完全一致。而最后多出的0并不影响这个索引条目的使用。类似的我们可以使用相同的方法来依次验证另外两个键值都是符合理论值的。数据都在一个数据块里的情况比较容易理解。如果被索引的数据分布在多个数据块里呢经常会有人问到只记录start rowid和end rowid如果被索引的记录分布在多个数据块里那么oracle如何根据start rowed来找到bitmap里的bit1所对应的记录的rowid呢创建一个表[php]SQL create table t_bitmap_2(id number,bitcol char(2000));insert into t_bitmap_2 values(1,A);insert into t_bitmap_2 values(2,A);insert into t_bitmap_2 values(3,A);insert into t_bitmap_2 values(4,B);insert into t_bitmap_2 values(5,A);insert into t_bitmap_2 values(6,A);insert into t_bitmap_2 values(7,B);insert into t_bitmap_2 values(8,A);insert into t_bitmap_2 values(9,A);insert into t_bitmap_2 values(9,A);insert into t_bitmap_2 values(10,B);insert into t_bitmap_2 values(11,B);insert into t_bitmap_2 values(12,B);insert into t_bitmap_2 values(13,B);insert into t_bitmap_2 values(14,B);insert into t_bitmap_2 values(15,B);COMMIT;_______________[/php]获得这15条记录所在的数据块号[php]SQL select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,2 dbms_rowid.rowid_block_number(rowid) as block#3 from t_bitmap_2;FILE# BLOCK#---------- ----------3 74283 74293 74303 74313 74323 7433_______________[/php]可以知道这15条记录分布在6个数据块里。然后跟踪对于bitcol列上的bitmap索引的创建过程[php]alter session set events 10608 trace name context forever, level 10;create bitmap index idx_t_bitmap_2 on t_bitmap_2(bitcol);alter session set events 10608 trace name context off;_______________[/php]从转储出来的文件可以看到最终形成了两个索引条目……qerbiCon: key: (2000):41 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20……srid00c01d04.0 erid00c01d08.7 bitmap: (11): c8 06 c0 44 f8 b3 01 07 f8 56 06……qerbiCon: key: (2000):42 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20……srid00c01d04.0 erid00c01d09.7 bitmap: (12): 00 f8 56 06 f8 56 07 c0 a1 01 c0 44*** 2008-06-10 11:21:08.000很明显这里的两个索引条目的start rowed和end rowed是不相同的。键值为A的索引条目为srid00c01d04.0 erid00c01d08.7 bitmap: (11): c8 06 c0 44 f8 b3 01 07 f8 56 06其数据块从1d04到1d08也就是[php]SQL select sys.pkg_number_trans.f_hex_to_dec(1d04) as s_blk#,2 sys.pkg_number_trans.f_hex_to_dec(1d08) as e_blk#3 from dual;S_BLK# E_BLK#---------- ----------7428 7432_______________[/php]而键值B的索引条目为srid00c01d04.0 erid00c01d09.7 bitmap: (12): 00 f8 56 06 f8 56 07 c0 a1 01 c0 44其数据块从1d04到1d09也就是[php]SQL select sys.pkg_number_trans.f_hex_to_dec(1d04) as s_blk#,2 sys.pkg_number_trans.f_hex_to_dec(1d09) as e_blk#3 from dual;S_BLK# E_BLK#---------- ----------7428 7433_______________[/php]这个时候[php]SQL select substr(bitcol,1,1) as bitcol,dbms_rowid.rowid_block_number(rowid) as block# from t_bitmap_2;BI BLOCK#-- ----------B 7428A 7428A 7428A 7429B 7429B 7429B 7430B 7430B 7430A 7431A 7431A 7431B 7432A 7432A 7432B 7433_______________[/php]这时oracle放了很多的bit来对应这15条记录但是oracle如何根据这些bit位来找对应的rowid就猜不出了。还希望各位牛人继续补充。[本帖最后由 hanson 于 2008-6-10 17:26 编辑]
