En général, si vous n'utilisez pas RAC, il n'y a aucune raison d'utiliser un index à clé inversée.
Du point de vue des performances, il est bien préférable d'avoir un ou deux blocs chauds à un moment donné qui sont soumis à des insertions, car cela garantit essentiellement que les blocs chauds seront dans le cache de tampon et le INSERT n'aura pas à supporter le coût de la lecture du bloc à partir du disque. Si vous avez des insertions dans des blocs aléatoires dans un index, il y a une bien plus grande probabilité que le bloc que vous voulez ait vieilli hors du cache et entraîne le coût d'une E/S physique.
Le coût de maintien d'un indice équilibré est assez minime, mais même cela favorise un indice standard. Si vous avez une séquence de clé primaire générée avec un index normal, Oracle fera un Répartition des blocs 90/10 sur le bloc le plus à droite lorsque ce bloc se remplit. En revanche, si vous avez un index de clé inversé, Oracle doit faire Divisions de blocs 50/50 chaque fois qu'un bloc donné se remplit. Un fractionnement de bloc 50/50 copie la moitié des données de l'ancien bloc vers le nouveau bloc, un fractionnement de bloc 90/10 ne copie que la valeur de données la plus à droite vers le nouveau bloc. Le fractionnement de blocs 90/10 est donc beaucoup moins cher qu'un fractionnement de blocs 50/50 et vous devrez effectuer à peu près le même nombre de fractionnements de blocs quel que soit le type d'index que vous choisissez. Ainsi, le coût de maintenance d'un index régulier est inférieur au coût de maintenance d'un index à clé inversée, même en ignorant l'effet du cache.
La raison pour laquelle vous envisagez d'utiliser un index de clé inverse serait que vous utilisez RAC et que vous souhaitez éviter le coût d'avoir de nombreux nœuds RAC qui se battent tous sur le même bloc chaud. Si vous devez constamment expédier le bloc chaud d'un nœud à un autre afin de faire l'insertion suivante, il peut être intéressant d'utiliser un index de clé inversée à la place pour réduire ce conflit. Si vous disposez d'une licence pour l'option de partitionnement, il serait encore préférable d'utiliser un index partitionné par hachage à la place (cela peut être fait que les tables soient partitionnées ou non). Si vous n'avez pas de licence pour l'option de partitionnement, un index de clé inversée peut suffire à résoudre les conflits sur le bloc chaud pour ne pas nécessiter de licence de partitionnement.
