反向键索引是一种 B-tree 索引, 它在保持列顺序的同时, 物理地改变每个索引键的字节 (反向键索引除了 ROWID 和 still 之外, 反转每个索引列的字节). 例如, 如果索引键为 20, 如果在十六进制中存储为这个键的两个字节是 C1, 则是标准 b 树索引中的 15 个字节, 那么一个反向键索引将字节存储为 15,C1.
优点:
反转键解决了 b 树索引右侧叶块争用的问题. 这个问题在 Oracle Real Application cluster (Oracle RAC) 数据库中尤其突出, 在这个数据库中多个实例反复修改同一个块. 例如, 在 orders 表中, 订单的主键是顺序的. 集群中的一个实例添加了 order 20, 而另一个实例添加了 21, 每个实例都将其关键字写入索引右侧的同一个叶块.
在反向键索引中, 字节顺序的反转分布在索引中的所有叶键上. 例如, 在标准键索引中相邻的 20 和 21 这样的键现在被分开存储在不同的块中 (索引会在左边, 中间, 右边 - 到处都是). 所以争论就这样消失了. 因此, 顺序键插入的 I/O 分布更均匀.
缺点:
但是, 必须指出的是: 现在整个索引最好在缓冲区缓存中, 而在之前 -- 只有热的右侧需要在缓存中进行有效的插入. 如果索引不能放入缓存, 我们很可能会将缓冲区繁忙的等待变成物理 IO 等待, 这可能更糟 (补救比症状更糟糕).
由于索引中的数据在存储时没有按列键排序, 所以反向键安排在某些情况下消除了运行索引范围扫描查询的能力. 例如, 如果用户对大于 20 的订单 ID 发出查询, 那么数据库就不能从包含该 ID 的块开始, 然后水平地通过叶块进行.
总结:
这些索引旨在消除插入应用程序上的索引热点. 这些索引对于插入性能非常好, 但是它们是有限的, 因为数据库不能使用它们进行索引范围扫描.
语法:
- create index <INDEX_NAME> on <TABLE_NAME> (<COLUMN_NAME>, <COLUMN_NAME>)
- REVERSE;
参考: What Are Reverse Key Indexes? (文档 ID 1070627.6)
来源: http://www.linuxidc.com/Linux/2018-08/153361.htm