Oracle反转索引

Oracle反转索引

 

当载入一些有序数据时，索引肯定会碰到与I/O相关的一些瓶颈。在数据载入期间，某部分索引和磁盘肯定会比其他部分使用频繁得多。为了解决这个问题，可以把索引表空间存放在能够把文件物理分割在多个磁盘上的磁盘体系结构上。

 

为了解决这个问题，Oracle还提供了一种反转键索引的方法。如果数据以反转键索引存储，这些数据的值就会与原先存储的数值相反。这样，数据1234、1235和1236就被存储成4321、5321和6321。结果就是索引会为每次新插入的行更新不同的索引块。

 

不能对位图索引和索引组织表进行反转键处理。

 

技巧：

如果您的磁盘容量有限，同时还要执行大量的有序载入，就可以使用反转键索引。

不可以将反转键索引与位图索引或索引组织表结合使用。

 

转自：http://baike.baidu.com/item/反向键索引?fr=aladdin

 

 

ORACLE DBA实践之三十：创建反转关键字索引

转自：http://blog.sina.com.cn/s/blog_7e662b4a0100veeq.html

 

     对于大型联机事务处理系统来说，其中的表一般都很大，在这些表的主键是由序列号产生的，而且上面是有索引的。因此相邻的索引记录就可能存在同一个数据块中，这样会形成数据块的竞争。而随着时间流逝，会不断在这些表中删除旧的无用的数据，插入新的有用的数据，很显然删除的数据是序列号很小的旧数据，而插入的数据序列号是刚刚产生的（一定是大号），这就造成了另一个严重的问题：即该索引的树是往序列号大的一面偏，因此会使得树的深度加深从而使系统效率下降。

   为了解决上述问题，oracle引入了反转关键字索引。反转关键字索引通过将关键字（序列号）的每个字节顺序颠倒过来再建索引的方法实现的。举例如下：

反转前

反转后

Order#

Order#

1230

0321

1231

1321

1232

2321

….

….

由上可见，原来相邻的order#经反转之后就不再相邻了，这样就可以把相邻的order#分散到不同的数据块中，上述问题也就迎刃而解。

     但事物总是一分为二的，反转索引关键字也存在问题。例如在反转关键字索引的表上进行范围查询就会遇到麻烦。在正常索引的况下，满足条件的索引记录应该放在同一个或相邻的数据块中，速度会很快；而使用反转关键字索引之后，原来相邻的满足条件的索引记录已经被分散到多个数据块中，此事要完成查询操作只能进行全表扫描。因此在决定是否使用反转关键字索引时，要分清是插入操作重要，还是范围查询重要。

 

 

转自：http://blog.itpub.net/22034023/viewspace-666018/

 

最近通过反转索引优化了几个数据库性能问题，但也同时总结了他的几个缺点。

1）由于反转索引存储键值的特点，导致不支持范围查找。如<.> between.

2）反转索引会导致聚簇因子过高，但这个缺点并不太值得我们考虑，原因一是因为既然选择了反转索引，那么这个索引就应该是字段递增且唯一值非常高，在做等值查询的时候一般是不会扫描太多的数据块。原因二是由于反转索引不支持范围查找，这又大大的削减了聚簇因子的作用。

3）反转索引会导致索引的物理读加大。这是由于翻转后的键值几乎都不可能是上次插入的数据块，往往都已经被从共享池淘汰出去，或是需要找寻新的数据块来插入，所以物理读会明显的大。