首先得明确索引都是有序排列的。
而反向索引最大的用处是用在集群环境中的。试想这样一种情况，一个插入非常频繁的表A，在列ID存在一个索引INDEX_A_ID，假如索引的生成顺序是每次插入加1。如：
123
124
125
那么这几个索引键值非常非常大的可能是存储在一个数据块上的，而在集群环境中，数据块需要申请DLM锁来进行数据块的传递。
这样的话，问题就出来了，对于插入非常频繁的表，如果存在类似的索引，数据块在集群间的传递就非常频繁，这样的话肯定影响性能。
如果是反转索引的话，情况就明显不一样了，以上面的例子来说，翻转后，键值的顺序是：
321
421
521
这几个键值存在一个数据块的可能性大大降低了。因此数据块的在集群间的传递争用就会消失。我现在所维护的双节点RAC，前段时间有几个索引一直出现在AWR中（哪个部分我忘了，记不清了），就是因为上面的情况，建立了反转索引后，彻底消失了。
但反向键索引也有它局限性：如果在WHERE语句中，需要对索引列的值进行范围性的搜索，如BETWEEN、<、>等，其反向键索引无法使用，这个时候，Oracle将执行全表扫描；只有对反向键索引列进行 <> 和 = 的比较操作时，其反向键索引才会得到使用。
而反向索引最大的用处是用在集群环境中的。试想这样一种情况，一个插入非常频繁的表A，在列ID存在一个索引INDEX_A_ID，假如索引的生成顺序是每次插入加1。如：
123
124
125
那么这几个索引键值非常非常大的可能是存储在一个数据块上的，而在集群环境中，数据块需要申请DLM锁来进行数据块的传递。
这样的话，问题就出来了，对于插入非常频繁的表，如果存在类似的索引，数据块在集群间的传递就非常频繁，这样的话肯定影响性能。
如果是反转索引的话，情况就明显不一样了，以上面的例子来说，翻转后，键值的顺序是：
321
421
521
这几个键值存在一个数据块的可能性大大降低了。因此数据块的在集群间的传递争用就会消失。我现在所维护的双节点RAC，前段时间有几个索引一直出现在AWR中（哪个部分我忘了，记不清了），就是因为上面的情况，建立了反转索引后，彻底消失了。
但反向键索引也有它局限性：如果在WHERE语句中，需要对索引列的值进行范围性的搜索，如BETWEEN、<、>等，其反向键索引无法使用，这个时候，Oracle将执行全表扫描；只有对反向键索引列进行 <> 和 = 的比较操作时，其反向键索引才会得到使用。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/22034023/viewspace-662246/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
ORACLE 监控索引的使用
请登录后发表评论
登录
全部评论
