¿Hay algún beneficio en cierto orden de columnas al definir índices?

13

Por ejemplo, si tengo dos índices:

CREATE INDEX IDX_1 ON MY_TABLE_1
 (ITEM, DATE, LOCATION)
 COMPUTE STATISTICS;

CREATE INDEX IDX_2 ON MY_TABLE_1
 (DATE, LOCATION, ITEM)
 COMPUTE STATISTICS;

¿Esto sería IDX_2redundante? Si no, ¿cómo determino el orden de declaración de las columnas?

¿Debería adaptar los índices a las consultas regulares?

oracle index

— Lewis Norton
fuente

12

Sí, el beneficio se produce cuando desea consultar una parte del índice. Si coloca los predicados parcialmente utilizados primero, el índice puede usarse para consultas que involucren esos predicados pero no todas las columnas del índice.

Además, a menos que tenga otros requisitos, puede ayudar poner primero los predicados más selectivos, ya que esto puede reducir las operaciones de búsqueda de índice más rápido.

En su caso, IDX_2no es necesariamente redundante dependiendo de la naturaleza de las consultas en la tabla. Sin embargo, puede no ser necesario incluir todas las columnas. Si, por ejemplo, hace muchas consultas locationy dateluego IDX_2puede ser útil para ayudar a resolver esas consultas, ya IDX_1que no está en el orden correcto para ser útil para eso. Sin embargo, itemes posible que encuentre que es redundante IDX_2.

A partir del 9i, Oracle introdujo un operador de 'omisión de escaneo' donde las columnas de índice finales pueden consultarse de manera más eficiente, lo que puede reducir la necesidad de índices suplementarios de este tipo.

En un caso más específico, si está consultando itempor locationy datey no necesita ninguna otra columna, entonces la consulta podría resolverse completamente a través del índice sin tener que leer nada de la tabla. También puede crear índices de cobertura que tengan columnas no indexadas adjuntas. Si todas las columnas necesarias se pueden resolver desde el índice de cobertura, la consulta no necesita tocar la tabla principal.

Finalmente, en respuesta a su última pregunta: si tiene un conjunto de consultas usadas regularmente que están utilizando muchos recursos y podrían ajustarse utilizando un índice, entonces vale la pena considerarlo. Sin embargo, el mantenimiento de los índices conlleva una sobrecarga en las inserciones, por lo que tendrá que intercambiar el rendimiento de la consulta con la sobrecarga que los índices colocan en las operaciones de inserción o actualización.

— Preocupado por TunbridgeWells
fuente

3

@ConcernedOfTunbridgeWells: un enfoque alternativo es utilizar la compresión de clave de índice y tener las columnas menos selectivas (menos valores distintos) al frente. Ayuda a generar un índice más pequeño, al tiempo que permite que los saltos escaneados funcionen bien.

— Adam Musch

2

Otra cosa a tener en cuenta son las columnas con muchos valores nulos.

Si estas columnas tienen columnas especificadas después de ellas en el índice, los valores nulos deben indexarse. De lo contrario, como de costumbre, los valores nulos no se indexan (por supuesto, esto supone que está utilizando un índice b-tree).

Por lo tanto, si tiene columnas con una gran cantidad de valores nulos, colocarlas al final del índice puede ahorrarle una cantidad significativa de espacio en disco.

— Michal Tenenberg
fuente