b树
索引空间分配原理讨论
果新关键字值在所有旧叶节点块的所有关键字中是最大的，那么所有的关键字将按照
9 9 : 1的比例进行拆分，使得在新的叶节点块中只存放有新关键字，而其他的所有关键字
（包括所有删除的关键字）仍然保存在旧叶节点块中。
如果新关键字值不是最大的，那么所有的关键字将按照5 0 : 5 0的比例进行拆分，这时每
个叶节点块（旧与新）中将各包含原始叶节点中的一半关键字。
索引空闲列表并不能帮助Oracle查找一个
可用来存放将要被插入的新关键字的块。这是因为关键字值不能随机地存放在索引中可用的
第一个“空闲”叶节点块中，这个值必须经过适当的排序之后，放置在某个特定的叶节点块
中。只有在块拆分过程中才需要使用索引的空闲列表，每个空闲列表都包含有一个关于“空”
块的链接列表。当为某个索引定义了多个空闲列表时，首先将从分配给进程的空间列表中扫
描一个空闲块。如果没有找到所需要的空闲块，将从主空闲列表中进行扫描空闲块的动作。
请记住，一个关键字在B树中有且只有一个位置。因此，当某个关键字发生改变时，关键字
的旧表项必须被删除，并且需要在一个新的叶节点上创建一个新的关键字。旧的表项有可能永
远不会被重新使用，这是因为只有在非常特殊的情况下， Oracle才会重用关键字表项槽，
例如，新插入的关键字正好是被删除的那个关键字（包括数据类型、长度等等）。那么，这种
情况发生的可能性有多大呢？本客户站点中的许多应用程序使用一个数列来产生NUMBER
关键字（特别是主关键字）。除非它们使用了RECYCLE选项，否则这个数列将不会两次
产生完全相同的数。这样，索引中被删除的空间一直没有被使用。这就是在大规模删除与更新
过程中，表大小不断减小或至少保持不变但索引不断加大的原因。所以对于这种情况就需要
alter index rebuild online;
9i以上，可以监控索引的使用情况，如果一段时间内没有使用的索引，一般就是无用的索引
语法为：
开始监控：alter index index_name monitoring usage;
检查使用状态：select * from v$object_usage;
停止监控：alter index index_name nomonitoring usage;
注意上面的语句可能影响性能，所以你可以找一个比较典型的时间段，来启动监控，然后找出
不合理的索引，删除这些索引，然后停止监控
的应用准则：
>避免对那些可能会产生很高的更新动作的列进行索引。
>避免对那些经常会被删除的表中的多个列进行索引。
另外对于null值不会写到索引中，所以column is null 不能使用索引
索引的pctfree:
索引与表在处理pct方面的不同在于，在做更新时，并不想表那样，而是因为索引键值对应唯一位置，
那么等于这个老位置不在用了，而跑到新的物理位置，但是表的话，物理位置不会变的。所以这些更
新动作没有任何意义。对于索引，PCTFREE大多数是在索引创建过程中发生作用，可以用一个非零值
来说明块拆分比例。如果在索引创建过程中，PCTFREE被设置为20，那么有80％的叶节点将可能会包
含关键字信息。但是，剩余的20％将用来作为关键字信息后来插入到叶节点块中时使用。这样将能够
保证在需要进行叶节点块的拆分时，运行时的插入开销最小，不要进行大量的块间移动。所以索引没
有用pctuser,是不限制ORACLE插入到pctfree部分。所以如果空间允许，我想还是尽量设置PCTFREE
大点（oltp）
对于任何其键值不断增加的列，也就是说，比如一个主键用序列器生成，只会增加键值到最大值，那么
他几乎不需要中间接点插入某个值，所以对于pctfree意义也不大，所以最好是设置一个非常低的
PCTFREE（甚至可以为0）。因为这样就会只有那些最右方的叶节点块总是会被插入，从而使得树向右增长。
而左边的叶节点将一直为静止状态，因此没有必要使得这些块的任何部分为空（通过使用非零PCTFREE）
比如
4个叶节点，每个节点可以存5个键值，总共有16个值
20%pctfree :
节点1 节点2 节点3 节点4
1,2,3,4,等待插入的值 5,6,7,8,等待插入的值 9,10,11,12,等待插入的值 13,14,15,16,等待插入的值
0%pctfree :
节点1 节点2 节点3 节点4
1,2,3,4,5 6,7,8,9,10 11,12,13,14,15 16,等待插入,等待插入,等待插入,等待插入
所以我们分析，如果是序列器生成的，那么就可以用0%pctfree方案，这样就只会牵涉到最后一个叶节点，
而不需要很多拆分
而20%pctfree则比较合适对于新增比如8.9的，这样就可以运行的插入开销最小，直接插入节点2
阅读(2716) | 评论(0) | 转发(0) |
