Tenemos una mesa grande, con varios índices (por ejemplo, I1-I5).

El patrón de uso es el siguiente:

Aplicación A: todas las consultas de selección al 100% usan los índices I1-I4 (se supone que están diseñadas lo suficientemente bien como para que nunca usen I5).

Aplicación B: solo tiene una consulta de selección (ejecutada con bastante frecuencia), que contiene 6 campos y para la cual se creó un quinto índice I5 como un índice cubierto.

Los primeros 2 campos del índice cubierto son la fecha y una identificación de seguridad. La tabla contiene filas para ~ 100 fechas (en orden de fecha, impuestas por un índice agrupado I1) y decenas de miles de identificadores de seguridad.

Pregunta: ¿el orden de las columnas en el índice cubierto afecta el rendimiento de la consulta de selección en la Aplicación B?

Es decir, ¿cambiaría el rendimiento de la consulta si cambiamos los dos primeros campos del índice (fecha e ID de seguridad)? ¿Cambiaría el rendimiento de la consulta si cambiamos alrededor de uno de los últimos campos?

Supongo que los IO lógicos no se verán afectados por ningún orden de campos en el índice cubierto (aunque no estoy seguro al 100%).

¿Pero habrá otros efectos de rendimiento? (Optimizador de velocidad, caching, etc ...)

La pregunta es versión genérica, pero si importa, usamos Sybase 12.

Desafortunadamente, la tabla es tan enorme que es realmente difícil cambiar el índice en la práctica y confirmar cuantitativamente los efectos del cambio.