I allmänhet, om du inte använder RAC, skulle det inte finnas någon anledning att använda ett omvänd nyckelindex.
Ur prestandasynpunkt är du mycket bättre av att ha ett eller två heta block vid en given tidpunkt som är föremål för infogning eftersom det i huvudsak garanterar att de heta blocken kommer att finnas i buffertcachen och INSERT kommer inte att behöva ta på sig kostnaden för att läsa blocket från disken. Om du har inlägg som går in i slumpmässiga block i ett index, är det mycket större sannolikhet att blocket du vill ha skulle ha åldrats ur cachen och skulle medföra kostnaden för en fysisk I/O.
Kostnaden för att hålla ett index balanserat är ganska minimalt men även det gynnar ett standardindex. Om du har en sekvensgenererad primärnyckel med ett normalt index kommer Oracle att göra en 90/10 block split på blocket längst till höger när det blocket fylls. Om du däremot har ett omvänt nyckelindex måste Oracle göra 50/50 blockuppdelningar när ett givet block fylls upp. En 50/50-blockdelning kopierar hälften av datan från det gamla blocket till det nya blocket, en 90/10-blockdelning kopierar endast datavärdet längst till höger till det nya blocket. Blockdelningen 90/10 är därför mycket billigare än en 50/50-blockdelning och du skulle behöva göra ungefär samma antal blockdelningar oavsett vilken typ av index du väljer. Så kostnaden för att upprätthålla ett vanligt index är mindre än kostnaden för att upprätthålla ett omvänt nyckelindex även om man ignorerar effekten av cache.
Anledningen till att du skulle överväga att använda ett omvänt nyckelindex skulle vara att du använder RAC och du vill undvika kostnaden för att ha många RAC-noder som alla slåss om samma hot block. Om du hela tiden måste skicka hotblocket från en nod till en annan för att göra nästa infogning, kan det vara värt att använda ett omvänt nyckelindex istället för att minska det påståendet. Om du har licensierat partitioneringsalternativet skulle det fortfarande vara bättre att använda ett hashpartitionerat index istället (detta kan göras oavsett om tabellerna är partitionerade eller inte). Om du inte har licensierat partitioneringsalternativet kan ett omvänt nyckelindex vara tillräckligt bra för att lösa konflikter på hot blocket för att inte kräva att du licensierar partitionering.