【IT168 技术文档】索引的高度(Btree Level)是影响索引的性能的因素之一，高度的增加，意味着对索引的读的次数的增加。如果索引高度要增加，其必要条件就是左枝或右枝饱和。

　　枝节点中左节点是个特殊的节点，它是枝节点数据块中唯一小于该枝节点键值的节点，其指针并不在枝节点的数据区，而是在枝节点数据块的头部，并且它没有记录所指向节点的键值，而只有一个指针，并且每个枝节点都必须有一个左节点。对于右节点，因为索引长度是受限制的(和数据块大小相关)，保证了一个节点中最少能放入一个键值。这2个特性决定了一个枝节点最少可以指向2个下一层节点。因此，即使索引键值数据足够大，要构建一颗高度为N的树也需要2^(n-1)条数据，最终的索引节点块为2^n-1块。例如，在一个块大小为2K的表空间中构建一个24层的索引，将需要32G的索引空间。

　　然而，在9i中，B树的左增长在算法上有缺陷：分裂时，如果枝节点已经饱和，则枝节点立即分裂。这样的话，在左分裂时，如果左枝上的所有枝节点已经全部饱和，即使右枝节点没有任何键值指针，也会造成左枝的“多米诺”式的分裂，造成树的高度增加(因为每个枝节点必须有一个左节点，因此右分裂不会造成这种情况)。利用这一缺陷，Jonathan Lewis只用24条数据就构建了一个24层高度的B树。

　　在10g中，这一缺陷已经被修正了：左枝节点饱和时，会先看其同父节点的右枝节点上是否有索引键数据(即是否存在指向右边的指针)，如果没有，则将左枝节点上的数据转移到右枝节点，从而释放左枝节点的空间。

　　那是不是在10g中，如果需要构建一颗“高”数，就必须要如此大的空间呢?实际上，我们还可以利用右分裂的一个规则生成一个size很小但层数很高的索引：右分裂时，只要右枝节点是饱和就会分裂，而没有考虑对应的左枝节点上是否存在键值数据。利用这一规则，我们在构造出右枝的第一节点后，就将左枝上的右边数据删除，从而保证索引只占用少量数据。不过这一方法还是需要大量的中间数据。以下代码中，实际生成的表(HWM)、索引不足1M。

　　还有一点就是，节点数据块为空后，会被放到freelist的头部去，当索引分裂需要新数据块时，会先从freelist的头部先取出数据块进行分配，因此这就是我们以下代码能始终保证索引的size很小的原因。

　　注意：下面代码不要在生产环境上运行，运行前建议关闭Archive模式。

　　达到索引高度限制(24)后 ，以上代码抛出了600错误。　

　　以上代码在PC server上运行了5个小时，表和索引的高水位都不足1M：　

　　值得注意的是，在OLTP系统中，因为会对表进行大量的增、删、改，难免会出现上述情况——右(左)增长时，左(右)枝存在很大空闲，造成这样的现象：数据量很少，但索引树的高度却很高。