B树索引（三、四）

最新推荐文章于 2020-11-28 05:56:44 发布

爱笑的余尔吖

最新推荐文章于 2020-11-28 05:56:44 发布

阅读量591

点赞数

分类专栏：索引技术

索引技术专栏收录该内容

7 篇文章 0 订阅

订阅专栏

3. B 树索引的访问

我们已经知道了B树索引的体系结构，那么当oracle需要访问索引里的某个索引条目时，oracle是如何找到该索引条目所在的数据块的呢？

当oracle进程需要访问数据文件里的数据块时，oracle会有两种类型的I/O操作方式：

1）随机访问，每次读取一个数据块（通过等待事件“db file sequential read”体现出来）。

2）顺序访问，每次读取多个数据块（通过等待事件“db file scattered read”体现出来）。

第一种方式则是访问索引里的数据块，而第二种方式的I/O操作属于全表扫描。这里顺带有一个问题，为何随机访问会对应到db file sequential read等待事件，而顺序访问则会对应到db file scattered read等待事件呢？这似乎反过来了，随机访问才应该是分散（scattered）的，而顺序访问才应该是顺序（sequential）的。其实，等待事件主要根据实际获取物理I/O块的方式来命名的，而不是根据其在I/O子系统的逻辑方式来命名的。下面对于如何获取索引数据块的方式中会对此进行说明。

我们看到前面对B树索引的体系结构的描述，可以知道其为一个树状的立体结构。其对应到数据文件里的排列当然还是一个平面的形式，也就是像下面这样。因此，当oracle需要访问某个索引块的时候，势必会在这个结构上跳跃的移动。

/根/分支/分支/叶子/…/叶子/分支/叶子/叶子/…/叶子/分支/叶子/叶子/…/叶子/分支/.....

当oracle需要获得一个索引块时，首先从根节点开始，根据所要查找的键值，从而知道其所在的下一层的分支节点，然后访问下一层的分支节点，再次同样根据键值访问再下一层的分支节点，如此这般，最终访问到最底层的叶子节点。可以看出，其获得物理I/O块时，是一个接着一个，按照顺序，串行进行的。在获得最终物理块的过程中，我们不能同时读取多个块，因为我们在没有获得当前块的时候是不知道接下来应该访问哪个块的。因此，在索引上访问数据块时，会对应到db file sequential read等待事件，其根源在于我们是按照顺序从一个索引块跳到另一个索引块，从而找到最终的索引块的。

那么对于全表扫描来说，则不存在访问下一个块之前需要先访问上一个块的情况。全表扫描时，oracle知道要访问所有的数据块，因此唯一的问题就是尽可能高效的访问这些数据块。因此，这时oracle可以采用同步的方式，分几批，同时获取多个数据块。这几批的数据块在物理上可能是分散在表里的，因此其对应到db file scattered read等待事件。

4. B树索引的管理机制

4.1 B树索引的对于插入（INSERT）的管理

对于B树索引的插入情况的描述，可以分为两种情况：一种是在一个已经充满了数据的表上创建索引时，索引是怎么管理的；另一种则是当一行接着一行向表里插入或更新或删除数据时，索引是怎么管理的。

对于第一种情况来说，比较简单。当在一个充满了数据的表上创建索引（create index命令）时，oracle会先扫描表里的数据并对其进行排序，然后生成叶子节点。生成所有的叶子节点以后，根据叶子节点的数量生成若干层级的分支节点，最后生成根节点。这个过程是很清晰的。

但是对于第二种情况来说，会复杂很多。我们结合一个例子来说明。为了方便起见，我们在一个数据块为2KB的表空间上创建一个测试表，并为该表创建一个索引，该索引同样位于2KB的表空间上。

SQL> create table
index_test(id char(150)) tablespace tbs_2k;

SQL> create index
idx_test on index_test(id) tablespace tbs_2k;

当一开始在一个空的表上创建索引的时候，该索引没有根节点，只有一个叶子节点。我们以树状形式转储上面的索引idx_test。

SQL> select object_id from user_objects
where object_name='IDX_TEST';

OBJECT_ID

----------

7390

SQL> alter session
set events 'immediate trace name treedump level 7390';

从转储文件可以看到，该索引中只有一个叶子节点（leaf）。

----- begin tree dump

leaf: 0x1c001a2
29360546 (0: nrow: 0 rrow: 0)

----- end tree dump

随着数据不断被插入表里，该叶子节点中的索引条目也不断增加，当该叶子节点充满了索引条目而不能再放下新的索引条目时，该索引就必须扩张，必须再获取一个可
用的叶子节点。这时，索引就包含了两个叶子节点，但是两个叶子节点不可能单独存在的，这时它们两必须有一个上级的分支节点，其实这也就是根节点了。于是，现在，我们的索引应该具有3个索引块，一个根节点，两个叶子节点。

我们来做个试验看看这个过程。我们先试着插入插入10条记录。注意，对于2KB的索引块同时PCTFREE为缺省的10％来说，只能使用其中大约1623字（2048×90％×88％）。对于表index_test来说，叶子节点中的每个索引条目所占的空间大约为161个字节（3个字节行头+1个字节列长+150个字节列本身+1个字节列长+6个字节ROWID），那么当我们插入将10条记录以后，将消耗掉大约1610个字节。

SQL> begin

2 for i in 1..10 loop

3 insert into index_test values
(rpad(to_char(i*2),150,'a'));

4 end loop;

5 end;

6 /

SQL> commit;

SQL> select
file_id,block_id,blocks from dba_extents where segment_name='IDX_TEST';

FILE_ID BLOCK_ID BLOCKS

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

7 417 32

SQL> alter system
dump datafile 7 block 418; --因为第一个块为块头，不含数据，所以转储第二个块。

打开跟踪文件以后，如下所示，可以发现418块仍然是一个叶子节点，包含10个索引条目，该索引块还没有被拆分。注意其中的kdxcoavs为226，说明可用空间还剩226个字节，说明还可以插入一条记录。之所以与前面计算出来的只能放10条记录有出入，是因为可用的1623字节只是一个估计值。

……

kdxcoavs 226

……

row#0[1087] flag:
-----, lock: 0

col 0; len 150; (150):

31 30 61 61 61 61 61 61 61 61 61 61 61 61 61
61 61 61 61 61 61 61 61 61 61

61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
61 61 61 61 61 61 61 61 61 61

col 1; len 6; (6): 01 c0 01 82 00 04

row#1[926] flag: -----,
lock: 0

……

接下来，我们再次插入一条记录，以便基本充满该叶子节点，使得剩下的可用空间不足以再插入一条新的条目。如下所示。

SQL> insert into index_test values(rpad(to_char(11*2),150,'a'));

这个时候我们再次转储418块以后会发现与前面转储的内容基本一致，只是又增加了一个索引条目。而这个时候，如果向表里再次插入一条新的记录的话，该叶子节点（418块）必须进行拆分。

SQL> insert into
index_test values(rpad(to_char(12*2),150,'a'));

SQL> alter system
dump datafile 7 block 418;

转储出418块以后，我们会发现，该索引块从叶子节点变成了根节点（kdxcolev为1，同时row#0部分的col 1为TERM表示根节点下没有其他分支节点）。这也就说明，当第一个叶子节点充满以后，进行分裂时，先获得两个可用的索引块作为新的叶子节点，然后将当前该叶子节点里所有的索引条目拷贝到这两个新获得的叶子节点，最后将原来的叶子节点改变为根节点。

……

kdxcolev 1

……

kdxbrlmc
29360547=0x1c001a3

……

row#0[1909] dba:
29360548=0x1c001a4

col 0; len 1; (1): 34

col 1; TERM

----- end of branch
block dump -----

同时，从上面的kdxbrlmc和row#0中的dba可以知道，该根节点分别指向29360547和29360548两个叶子节点。我们分别对这两个叶子节点进行转储看看里面放了些什么。

SQL> select dbms_utility.data_block_address_file(29360547),

2 dbms_utility.data_block_address_block(29360547) from dual;

DBMS_UTILITY.DATA_BLOCK_ADDRES
DBMS_UTILITY.DATA_BLOCK_ADDRES

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

7 419

SQL> select dbms_utility.data_block_address_file(29360548),

2 dbms_utility.data_block_address_block(29360548) from dual;

DBMS_UTILITY.DATA_BLOCK_ADDRES
DBMS_UTILITY.DATA_BLOCK_ADDRES

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

7 420

SQL> alter system dump datafile 7 block 419;

SQL> alter system dump datafile 7 block 420;

在打开跟踪文件之前，我们先来看看表index_test里存放了哪些数据。

SQL> select substr(id,1,2) from index_test order by substr(id,1,2);

SUBSTR(ID,1,2)

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

打开419块的跟踪文件可以发现，里面存放了10、12、14、16、18、20、22、24和2a；而420块的跟踪文件中记录了4a、6a和8a。也就是说，由于最后我们插入24的缘故，导致整个叶子节点发生分裂，从而将10、12、14、16、18、20、22、和2a放到419块里，而4a、6a和8a则放入420块里。然后，再将新的索引条目（24）插入对应的索引块里，也就是419块。

假如我们再最后不是插入12*2，而是插入9会怎么样？我们重新测试一下，返回到index_test里有11条记录的情况下，然后我们再插入9。

SQL> insert into index_test values (rpad('9',150,'a'));

这个时候，418块还是和原来一样变成了根节点，同时仍然生成出了2个叶子节点块，分别是419和420。但是有趣的是，419块里的内容与在插入9之前的叶子节点（当时的418块）的内容完全相同，而420块里则只有一个索引条目，也就是新插入的9。这也就是说，由于最后我们插入9的缘故，导致整个叶子节点发生分裂。但是分裂过程与插入12*2的情况是不一样的，这时该叶子节点的内容不进行拆分，而是直接完全拷贝到一个新的叶子节点（419）里，然后将新插入的9放入另外一个新的叶子节点（420）。我们应该注意到，插入的这个9表里所有记录里的最大字符串。

如果这时，我们再次插入12*2，则会发现419号节点的分裂过程和前面描述的一样，会将原来放在419块里的4a、6a和8a放入一个新的叶子节点里（421块），然后将12*2放入419块，于是这个时候419块所含有的索引条目为10、12、14、16、18、20、22、和2a。同时420块没有发生变化。

根据上面的测试结果，我们可以总结一下叶子节点的拆分过程。这个过程需要分成两种情况，一种是插入的键值不是最大值；另一种是插入的键值是最大值。

对于第一种情况来说，当一个非最大键值要进入索引，但是发现所应进入的索引块不足以容纳当前键值时：

1）从索引可用列表上获得一个新的索引数据块。

2）将当前充满了的索引中的索引条目分成两部分，一部分是具有较小键值的，另一部分是具有较大键值的。Oracle会将具有较大键值的部分移入新的索引数据块，而较小键值的部分保持不动。

3）将当前键值插入合适的索引块中，可能是原来空间不足的索引块，也可能是新的索引块。

4）更新原来空间不足的索引块的kdxlenxt信息，使其指向新的索引块。

5）更新位于原来空间不足的索引块右边的索引块里的kdxleprv，使其指向新的索引块。

6）向原来空间不足的索引块的上一级的分支索引块中添加一个索引条目，该索引条目中保存新的索引块里的最小键值，以及新的索引块的地址。

从上面有关叶子节点分裂的过程可以看出，其过程是非常复杂的。因此如果发生的是第二种情况，则为了

简化该分裂过程，oracle省略了上面的第二步，而是直接进入第三步，将新的键值插入新的索引块中。

在上例中，当叶子节点越来越多，导致原来的根节点不足以存放新的索引条目（这些索引条目指向叶子节点）时，则该根节点必须进行分裂。当根节点进行分裂时：

1）从索引可用列表上获得两个新的索引数据块。

2）将根节点中的索引条目分成两部分，这两部分分别放入两个新的索引块，从而形成两个新的分支节点。

3）更新原来的根节点的索引条目，使其分别指向这两个新的索引块。

因此，这时的索引层次就变成了2层。同时可以看出，根节点索引块在物理上始终都是同一个索引块。而

随着数据量的不断增加，导致分支节点又要进行分裂。分支节点的分裂过程与根节点类似（实际上根节点分裂其实是分支节点分裂的一个特例而已）：

1）从索引可用列表上获得一个新的索引数据块。

2）将当前满了的分支节点里的索引条目分成两部分，较小键值的部分不动，而较大键值的部分移入新的索引块。

3）将新的索引条目插入合适的分支索引块。

4）在上层分支索引块中添加一个新的索引条目，使其指向新加的分支索引块。

当数据量再次不断增加，导致原来的根节点不足以存放新的索引条目（这些索引条目指向分支节点）时，再次引起根节点的分裂，其分裂过程与前面所说的由于叶子节点的增加而导致的根节点分裂的过程是一样的。

同时，根节点分裂以后，索引的层级再次递增。由此可以看出，根据B树索引的分裂机制，一个B树索引始终都是平衡的。注意，这里的平衡是指每个叶子节点与根节点的距离都是相同的。同时，从索引的分裂机制可以看出，当插入的键值始终都是增大的时候，索引总是向右扩展；而当插入的键值始终都是减小的时候，索引则总是向左扩展。

本文转自

http://space.itpub.net/?uid-9842-action-viewspace-itemid-324139

4.2 B树索引的对于删除（DELETE）的管理

上面介绍了有关插入键值时索引的管理机制，那么对于删除键值时会怎么样呢？在介绍删除索引键值的机制之前，先介绍与索引相关的一个比较重要的视图：index_stats。该视图显示了大量索引内部的信息，该视图正常情况下没有数据，只有在运行了下面的命令以后才会被填充数据，而且该视图中只能存放一条与分析过的索引相关的记录，不会有第二条记录。同时，也只有运行了该命令的session才能够看到该视图里的数据，其他session不能看到其中的数据。

analyze index INDEX_NAME validate structure;

不过要注意一点，就是该命令有一个坏处，就是在运行过程中，会锁定整个表，从而阻塞其他session对表进行插入、更新和删除等操作。这是因为该命令的主要目的并不是用来填充index_stats视图的，其主要作用在于校验索引中的每个有效的索引条目都对应到表里的一行，同时表里的每一行数据在索引中都存在一个对应的索引条目。为了完成该目的，所以在运行过程中要锁定整个表，同时对于很大的表来说，运行该命令需要耗费非常多的时间。

在视图index_stats中，height表示B树索引的高度；blocks表示分配了的索引块数，包括还没有被使用的；pct_used表示当前索引中被使用了的空间的百分比。其值是通过该视图中的(used_space/btree_space)*100计算而来。used_space表示已经使用的空间，而btree_space表示索引所占的总空间；del_lf_rows表示被删除的记录行数（表里的数据被删除并不会立即将其对应于索引里的索引条目清除出索引块，我们后面会说到）；del_lf_rows_len表示被删除的记录所占的总空间；lf_rows表示索引中包含的总记录行数，包括已经被删除的记录行数。这样的话，索引中未被删除的记录行数就是lf_rows-del_lf_rows。同时我们可以计算未被删除的记录所对应的索引条目（也就是有效索引条目）所占用的空间为((used_space – del_lf_rows_len) / btree_space) * 100。

然后，我们还是接着上个例子（最后插入了12*2的例子）来测试一下。这时我们已经知道，该例中的索引具有两个叶子节点，一个叶子节点（块号为419）包含10、12、14、16、18、20、22、24和2a，而另一个叶子节点（块号为420）包含4a、6a和8a。我们插入41、42、43、44、45、46、47和48各8条记录，这时可以知道这8条记录所对应的索引条目将会进入索引块420中，从而该块420被充满。

SQL> begin

2 for i in 1..8 loop

3 insert into index_test values (rpad('4'||to_char(i),150,'a'));

4 end loop;

5 end;

6 /

我们先分析索引从而填充index_stats视图。

SQL> analyze index idx_test validate structure;

SQL> select LF_ROWS,DEL_LF_ROWS,DEL_LF_ROWS_LEN,USED_SPACE,BTREE_SPACE from index_stats;

LF_ROWS DEL_LF_ROWS DEL_LF_ROWS_LEN USED_SPACE BTREE_SPACE

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

20 0 0 3269 5600

从上面视图可以看到，当前索引共20条记录，没有被删除的记录，共使用了3269个字节。

然后我们删除位于索引块419里的索引条目，包括10、12、14、16各4条记录。

SQL> delete index_test where substr(id,1,2) in('10','12','14','16');

SQL> commit;

SQL> alter system dump datafile 7 block 419;

打开转储出来的文件可以发现如下的内容（我们节选了部分关键内容）。可以发现，kdxconro为3，说明该索引节点里还有9个索引条目。所以说，虽然表里的数据被删除了，但是对应的索引条目并没有被删除，只是在各个索引条目上（row#一行中的flag为D）做了一个D的标记，表示该索引条目被delete了。

kdxconro 9

row#0[443] flag: ---D-, lock: 2

row#1[604] flag: ---D-, lock: 2

row#2[765] flag: ---D-, lock: 2

row#3[926] flag: ---D-, lock: 2

然后，我们再以树状结构转储索引，打开树状转储跟踪文件可以看到如下内容。可以知道，块419里包含9个索引条目（nrow为9），而有效索引条目只有5个（rrow为5），那么被删除了的索引条目就是4个（9减5）。

SQL> alter session set events 'immediate trace name treedump level 7390';

----- begin tree dump

branch: 0x1c001a2 29360546 (0: nrow: 2, level: 1)

leaf: 0x1c001a3 29360547 (-1: nrow: 9 rrow: 5)

leaf: 0x1c001a4 29360548 (0: nrow: 11 rrow: 11)

----- end tree dump

这时，我们再次分析索引，填充index_stats视图。

SQL> analyze index idx_test validate structure;

SQL> select LF_ROWS,DEL_LF_ROWS,DEL_LF_ROWS_LEN,USED_SPACE,BTREE_SPACE from index_stats;

LF_ROWS DEL_LF_ROWS DEL_LF_ROWS_LEN USED_SPACE BTREE_SPACE

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

20 4 652 3269 5600

对照删除之前视图里的信息，很明显看到，当前索引仍然为20条记录，但是其中有4条为删除的，但是索引所使用的空间并没有释放被删除记录所占用的652个字节，仍然为删除之前的3269个字节。这也与转储出来的索引块的信息一致。

接下来，我们测试这个时候插入一条记录时，索引会怎么变化。分三种情况进行插入：第一种是插入一个属于原来被删除键值范围内的值，比如13，观察其会如何进入包含设置了删除标记的索引块；第二种是插入原来被删除的键值中的一个，比如16，观察其是否能够重新使用原来的索引条目；第三种是插入一个完全不属于该表中已有记录的范围的值，比如rpad('M',150,'M')，观察其对块419以及420会产生什么影响。

我们测试第一种情况：

SQL> insert into index_test values (rpad(to_char(13),150,'a'));

SQL> alter system dump datafile 7 block 419;

打开跟踪文件以后会发现419块里的内容发生了变化，如下所示。我们可以发现一个很有趣的现象，从kdxconro为6说明插入了键值13以后，导致原来四个被标记为删除的索引条目都被清除出了索引块。同时，我们也确实发现原来标记为D的四个索引条目都消失了。

……

kdxconro 6

……

kdxlende 0

……

row#0[121] flag: -----, lock: 2 被插入13

col 0; len 150; (150):

31 33 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61

……

我们分析索引，看看index_stats视图会如何变化。

SQL> analyze index idx_test validate structure;

SQL> select LF_ROWS,DEL_LF_ROWS,DEL_LF_ROWS_LEN,USED_SPACE,BTREE_SPACE from index_stats;

LF_ROWS DEL_LF_ROWS DEL_LF_ROWS_LEN USED_SPACE BTREE_SPACE

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

17 0 0 2780 5600

很明显，原来的del_lf_rows从4变为了0，同时used_space也从原来的3269变成了2780。表示原来被删除的索引条目所占用的空间已经释放了。

我们继续测试第二种情况：

SQL> insert into index_test values (rpad(to_char(8*2),150,'a'));

SQL> alter system dump datafile 7 block 419;

打开跟踪文件以后，发现对于插入已经被标记为删除的记录来说，其过程与插入属于该索引块索引范围的键值的过程没有区别。甚至你会发现，被插入的16的键值所处的位置与插入的13的键值所在的位置完全一样（row#0[121]里的121表示在索引块中的位置）。也就是说，oracle并没有重用原来为16的键值，而是直接将所有标记为D的索引条目清除出索引块，然后插入新的键值为16的索引条目。

对于第三种情况，我们已经可以根据前面有关第一、第二种情况做出预测，由于420块已经被充满，同时所插入的键值是整个表里的最大值，因此也不会因此420号块的分裂，而是直接获取一个新的索引块来存放该键值。但是419号块里标记为D的索引条目是否能被清除出索引块呢？

SQL> insert into index_test values (rpad('M',150,'M'));

SQL> alter system dump datafile 7 block 419;

SQL> alter system dump datafile 7 block 420;

SQL> alter system dump datafile 7 block 421;

打开跟踪文件，可以清楚的看到，419号块里的标记为D的4各索引条目仍然保留在索引块里，同时420号块里的内容没有任何变化，而421号块里则存放了新的键值：rpad('M',150,'M')。

我们看看index_stats视图会如何变化。其结果也符合我们从转储文件中所看到的内容。

SQL> analyze index idx_test validate structure;

SQL> select LF_ROWS,DEL_LF_ROWS,DEL_LF_ROWS_LEN,USED_SPACE,BTREE_SPACE from index_stats;

LF_ROWS DEL_LF_ROWS DEL_LF_ROWS_LEN USED_SPACE BTREE_SPACE

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

21 4 652 3441 7456

既然当插入rpad('M',150,'M')时对419号块没有任何影响，不会将标记为D的索引条目移出索引块。那么如果我们事先将419号索引块中所有的索引条目都标记为D，也就是说删除419号索引块中索引条目所对应的记录，然后再次插入rpad('M',150,'M')时会发生什么？通过测试，我们可以发现，再次插入一个最大值以后，该最大值会进入块421里，但是块419里的索引条目则会被全部清除，变成了一个空的索引数据块。这也就是我们通常所说的，当索引块里的索引条目全部被设置为D（删除）标记时，再次插入任何一个索引键值都会引起该索引块里的内容被清除。

最后，我们来测试一下，当索引块里的索引条目全部被设置为D（删除）标记以后，再次插入新的键值时会如何重用这些索引块。我们先创建一个测试表，并插入10000条记录。

SQL> create table delete_test(id number);

SQL> begin

2 for i in 1..10000 loop

3 insert into delete_test values (i);

4 end loop;

5 commit;

6 end;

7 /

SQL> create index idx_delete_test on delete_test(id);

SQL> analyze index idx_delete_test validate structure;

SQL> select LF_ROWS,LF_BLKS,DEL_LF_ROWS,USED_SPACE,BTREE_SPACE from index_stats;

LF_ROWS LF_BLKS DEL_LF_ROWS USED_SPACE BTREE_SPACE

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

10000 21 0 150021 176032

可以看到，该索引具有21个叶子节点。然后我们删除前9990条记录。从而使得21个叶子节点中只有最后一个叶子节点具有有效索引条目，前20个叶子节点里的索引条目全都标记为D（删除）标记。

SQL> delete delete_test where id >= 1 and id <= 9990;

SQL> commit;

SQL> analyze index idx_delete_test validate structure;

SQL> select LF_ROWS,LF_BLKS,DEL_LF_ROWS,USED_SPACE,BTREE_SPACE from index_stats;

LF_ROWS LF_BLKS DEL_LF_ROWS USED_SPACE BTREE_SPACE

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

10000 21 9990 150021 176032

最后，我们插入从20000开始到30000结束，共10000条与被删除记录完全不重叠的记录。

SQL> begin

2 for i in 20000..30000 loop

3 insert into delete_test values (i);

4 end loop;

5 commit;

6 end;

7 /

SQL> analyze index idx_delete_test validate structure;

SQL> select LF_ROWS,LF_BLKS,DEL_LF_ROWS,USED_SPACE,BTREE_SPACE from index_stats;

LF_ROWS LF_BLKS DEL_LF_ROWS USED_SPACE BTREE_SPACE

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

10011 21 0 160302 176032

很明显的看到，尽管被插入的记录不属于被删除的记录范围，但是只要索引块中所有的索引条目都被删除了（标记为D），该索引就变成可用索引块而能够被新的键值重新利用了。

因此，根据上面我们所做的试验，可以对索引的删除情况总结如下：

1）当删除表里的一条记录时，其对应于索引里的索引条目并不会被物理的删除，只是做了一个删除标记。

2）当一个新的索引条目进入一个索引叶子节点的时候，oracle会检查该叶子节点里是否存在被标记为删除的索引条目，如果存在，则会将所有具有删除标记的索引条目从该叶子节点里物理的删除。

3）当一个新的索引条目进入索引时，oracle会将当前所有被清空的叶子节点（该叶子节点中所有的索引条目都被设置为删除标记）收回，从而再次成为可用索引块。

尽管被删除的索引条目所占用的空间大部分情况下都能够被重用，但仍然存在一些情况可能导致索引空间

被浪费，并造成索引数据块很多但是索引条目很少的后果，这时该索引可以认为出现碎片。而导致索引出现碎片的情况主要包括：

1）不合理的、较高的PCTFREE。很明显，这将导致索引块的可用空间减少。

2）索引键值持续增加（比如采用sequence生成序列号的键值），同时对索引键值按照顺序连续删除，这时可能导致索引碎片的发生。因为前面我们知道，某个索引块中删除了部分的索引条目，只有当有键值进入该索引块时才能将空间收回。而持续增加的索引键值永远只会向插入排在前面的索引块中，因此这种索引里的空间几乎不能收回，而只有其所含的索引条目全部删除时，该索引块才能被重新利用。

3）经常被删除或更新的键值，以后几乎不再会被插入时，这种情况与上面的情况类似。

对于如何判断索引是否出现碎片，方法非常简单：直接运行ANALYZE INDEX … VALIDATE STRUCTURE

命令，然后检查index_stats视图的pct_used字段，如果该字段过低（低于50％），则说明存在碎片。

4.3 B树索引的对于更新（UPDATE）的管理

而对于值被更新对于索引条目的影响，则可以认为是删除和插入的组合。也就是将被更新的旧值对应的索

引条目设置为D（删除）标记，同时将更新后的值按照顺序插入合适的索引块中。这里就不重复讨论了。

图4

本文转自
http://space.itpub.net/?uid-9842-action-viewspace-itemid-324586

爱笑的余尔吖

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
B树索引（三、四）

3. B树索引的访问我们已经知道了B树索引的体系结构，那么当oracle需要访问索引里的某个索引条目时，oracle是如何找到该索引条目所在的数据块的呢？当oracle进程需要访问数据文件里的数据块时，oracle会有两种类型的I/O操作方式：1）随机访问，每次读取一个数据块（通过等待事件“db file sequential read”体现出来）。2）顺
复制链接

扫一扫