Cuando desea la máxima velocidad de recuperación y tiene ambas columnas en las condiciones de combinación o ubicación, PERO a veces la columna a tiene una selectividad más alta y, a veces, la columna b tiene una selectividad más alta, y desea capitalizar ese hecho desde un solo índice.
También creo que su proporción de tamaño de datos / rendimiento de la máquina debe ser bastante alta y, al mismo tiempo, tendrá que (estimar) estar dispuesto a llamar a cualquier mejora una necesidad (aunque solo sea por unos pocos porcentajes).
Aún así, la experiencia enseña que las cosas dependen de muchos factores; con RDBMS específicos y entornos de aplicación, es mejor que ejecute sus propios puntos de referencia.
EDITAR:explicación adicional sobre índices compuestos. de wikipedia
:
"El orden en que se enumeran las columnas en la definición del índice es importante. Es posible recuperar un conjunto de identificadores de fila utilizando solo la primera columna indexada. Sin embargo, no es posible ni eficiente (en la mayoría de las bases de datos) para recuperar el conjunto de identificadores de fila usando solo la segunda o mayor columna indexada.
Por ejemplo, imagine una guía telefónica que está organizada primero por ciudad, luego por apellido y luego por nombre. tienen la ciudad, puede extraer fácilmente la lista de todos los números de teléfono de esa ciudad. Sin embargo, en esta guía telefónica sería muy tedioso encontrar todos los números de teléfono para un apellido dado. Tendría que buscar dentro de la lista de cada ciudad. sección para las entradas con ese apellido."
Las explicaciones de Wikipedia tal vez estén demasiado simplificadas, pero le dan una idea básica (como analogías, tenga en cuenta que las guías telefónicas generalmente tienen índices agrupados y ese no sería el índice general de su base de datos).
Dependiendo del tamaño del índice frente al tamaño de la estructura de datos frente a la memoria disponible frente a la selectividad en la primera columna del índice, aún podría ser mucho menos costoso usar un índice ordenado incorrectamente que usar escaneos de tablas.
Ah, solo pensé en una analogía mejor con un ejemplo que está buscando Imagine un buen libro de texto, tendría una tabla de contenido con capítulos y subcapítulos y el número de páginas en las que se encuentran (que es un índice no agrupado que contiene punteros a registros de datos - páginas). Ahora imagine que el libro de texto está en el estándar SQL-92, entonces la mayoría de los términos en TOC serían términos SQL (mantenga esta suposición). También tendría otro índice al final del libro que sería enumere todos los términos interesantes en orden alfabético (supongamos que con los nombres de los capítulos principales) y números de página.
Para preguntas como "Dígame todos los capítulos en los que aparece DISTINCT", usaría el segundo índice (porque la selectividad del último campo es alta)
Para preguntas como 'Dígame el número de términos que aparecen en el primer capítulo', usaría el TOC
Entonces, para preguntas como "¿Se describe SELECT en el capítulo DML?" puede usar cualquiera de los índices (porque la selectividad de ambos campos es alta). Sin embargo, si TOC de DML en sí tiene 3 páginas y la entrada SELECT en el índice tiene solo quince líneas, probablemente iría a la segunda, y eso es un ejemplo de cuando te beneficias de ambos índices.
Ahora, si cree que eso es demasiado exagerado, tenga en cuenta una base de datos escaneada de la biblioteca del congreso. :)
Como dije antes, toda la planificación está bien, pero al final ejecute sus propios puntos de referencia.
