¿Buenas prácticas para usar índices inversos en claves sustitutas? (Oracle)

Question

Digamos que tengo una tabla con una clave sustituta autoincrementada.

¿Sería este un buen caso para usar un índice inverso?

Estoy en lo correcto al afirmar:

inserciones (en índice) serían más rápido .. ya que los nuevos valores se insertarían al azar, en lugar de ir siempre hacia la derecha más hojas (constantemente forzando reequilibra).

Las búsquedas de índice serían un poco más lentas ... ya que el db tendría que pasar (un poco) de tiempo invirtiendo el índice.

Dado que es una clave sustituta ... Realmente no necesitaría la capacidad de escaneo de rango (que no se puede hacer con índices inversos).

(Tenga en cuenta, no estoy usando Oracle RAC)

Answer 1

En general, si no se está usando el RAC, no habría ninguna razón para utilizar un índice de clave inversa.

Desde el punto de vista del rendimiento, es mucho mejor tener uno o dos bloques activos en un momento determinado que estén sujetos a inserciones, porque eso garantiza esencialmente que los bloques activos estarán en la memoria caché y el INSERT ganó No debe incurrir en el costo de leer el bloque desde el disco. Si tiene inserciones yendo a bloques aleatorios en un índice, hay una probabilidad mucho mayor de que el bloque que desea hubiera envejecido de la memoria caché e incurriera en el costo de una E/S física.

El costo de mantener un índice equilibrado es bastante mínimo, pero incluso eso favorece un índice estándar. Si tiene una clave principal generada por secuencia con un índice normal, Oracle hará un 90/10 block split en el bloque de la derecha cuando ese bloque se llene. Por el contrario, si tiene un índice de clave inversa, Oracle tiene que hacer 50/50 block splits cada vez que un bloque determinado se llena. Una división de bloques 50/50 copia la mitad de los datos del bloque anterior al bloque nuevo, una división de bloque 90/10 solo copia el valor de datos más derecho al bloque nuevo. La división de bloques 90/10, por lo tanto, es mucho más económica que una división de bloques 50/50 y tendría que hacer aproximadamente el mismo número de divisiones de bloques, independientemente del tipo de índice que elija. Entonces, el costo de mantener un índice regular es menor que el costo de mantener un índice de clave inversa, incluso ignorando el efecto de la memoria caché.

La razón por la que consideraría utilizar un índice de clave inversa sería que está utilizando RAC y desea evitar el costo de tener muchos nodos de RAC peleando por el mismo bloque caliente. Si tiene que enviar constantemente el bloque activo de un nodo a otro para hacer la siguiente inserción, puede valer la pena usar un índice de clave inversa para reducir esa contención. Si ha licenciado la opción de partición, sería mejor usar un índice de partición hash en su lugar (esto se puede hacer independientemente de si las tablas están particionadas o no). Si no ha licenciado la opción de partición, un índice de clave inversa puede ser lo suficientemente bueno para resolver la contención en el bloque de acceso rápido para no requerir que participe de licencia.