Oracle数据库中索引树的结构与块尺寸(1)

导读：关于Oracle数据库中索引树的结构以及它们对Oracle性能调优是否重要存在大量的、激烈的争论，而且已经有很多文章试图来描述这些重要的Oracle性能工具的内部工作机制。

正如我们知道的，Oracle提供了大量索引结构，每种索引结构都有其好处和不足：

以下是代码片段：

　create bitmap index   
part_suppliers_state   
on   
inventory( parts.part_type, supplier.state )   
from   
inventory i,   
parts p,   
supplier s   
where   
i.part_id=p.part_id   
and   
i.supplier_id=p.supplier_id;   

尽管有关索引重建的争论仍在激烈进行着，但还是存在每个人都认可的索引管理的某些领域。在内部机制上，一个Oracle B-树索引的结构和一个UNIX I-结点的结构非常相似。索引中的每个数据块都是索引树中的一个结点，位于最底部的结点(叶数据块)包含一对符号键和行ID值。

Oracle b-树索引

为了正确管理这些数据块，Oracle控制着每个数据块中指针的分配。随着一棵Oracle树的增长(通过往表里插入新行)，Oracle会填充这个数据块，当这个数据块满时Oracle会分裂它，创建新的索引结点(数据块)来管理索引内的符号键。

因此，一个Oracle索引块可能包含以下两种类型的指针：

Oracle管理着索引块内指针的分配，这就是为什么我们不能为索引指定一个PCTUSED值(自由列表重链接门槛)的原因。当我们检查一个索引块的结构时，我们发现每个索引结点内部条目的数量是下面两个值的一个函数：

1. 符号键的长度

2. 索引表空间的块尺寸

由于块尺寸影响每个索引结点内部的符号键的数量，可以推理出：块尺寸对一棵索引树的结构也会有影响。在其他条件相同的情况下，采用32K的大数据块能容纳更多的符号键，从而能够比在2K表空间中创建的相同的索引更加平整。采用大的数据块也将减少索引访问期间一致获取的数量，从而提高分散读访问的性能。

索引中的每个数据块包含索引树中的“结点”，位于最底部的结点(叶数据块)包含一对符号键和行ID值。随着一棵Oracle树的增长(通过往表里插入新行)，Oracle会填充这个数据块，当这个数据块满时Oracle会分裂它，创建新的索引结点(数据块)来管理索引内的符号键。因此，一个Oracle索引块可能包含指向其他索引结点或行ID/符号键对的指针。

索引行为和Oracle块尺寸

由于块尺寸影响每个索引结点内部的符号键的数量，可以推理出：块尺寸对一棵索引树的结构也会有影响。在其他条件相同的情况下，采用32K的大数据块能容纳更多的符号键，从而能够比在2K表空间中创建的相同的索引更加平整。

今天，大多数Oracle性能调优专家都利用Oracle提供的多种块尺寸的特色，因为它提供了缓冲区隔离和以最合适块尺寸来存放对象从而减少缓冲区浪费的能力。一些Oracle基准测试的世界记录都使用很大的数据缓冲区和多种块尺寸。

根据《Oracle数据库管理员认证：“Oracle 认证数据库管理专家”教师指南》一书的作者Christopher Foot的一篇文章，更大的块尺寸在某些情况下非常有帮助：

“更大的块尺寸意味着在B-树索引的分支结点中有更多的空间来存储符号键，从而可以降低树的高度和提高索引查询的性能。”

在任何情况下，似乎有证据表明块尺寸影响树的结构，这为数据块影响树的结构提供了有力支持。

你可以使用大数据块(16-32)缓冲区来存储来自作为重复性大规模扫描对象的索引或表中的数据。这真的会提高性能么？一个小的但透漏内情的测试能回答这个问题。