特定的场景使用，存在必有意义。只是意义的大小不同。

特定的场景使用，存在必有意义。只是意义的大小不同。

反向键索引是一种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的块开始，然后水平地通过叶块进行。

总结： 这些索引旨在消除插入应用程序上的索引热点。这些索引对于插入性能非常好，但是它们是有限的，因为数据库不能使用它们进行索引范围扫描。

主要是解决热快的问题，体现就是CBC latch 。 比如常访问 id 为 1，2，3 的数据，而这些数据在一个块中。现在反转后，1，2，3 的数据就在不同的块上，问题得到了缓解。 优缺点，自己体会下。