Múltiples índices versus índices de múltiples columnas

Acabo de agregar un índice a una tabla en SQL Server 2005 y me hizo pensar. ¿Cuál es la diferencia entre crear 1 índice y definir varias columnas sobre tener 1 índice por columna que desea indexar?

¿Hay ciertas razones por las cuales uno debería usarse sobre el otro?

Por ejemplo

Create NonClustered Index IX_IndexName On TableName (Column1 Asc, Column2 Asc, Column3 Asc) 

Versus

 Create NonClustered Index IX_IndexName1 On TableName (Column1 Asc) Create NonClustered Index IX_IndexName2 On TableName (Column2 Asc) Create NonClustered Index IX_IndexName3 On TableName (Column3 Asc) 

Estoy de acuerdo con Cade Roux .

Este artículo debería llevarlo por el buen camino:

  • Índices en SQL Server 2005/2008 – Mejores prácticas, Parte 1
  • Índices en SQL Server 2005/2008 – Parte 2 – Internals

Una cosa a tener en cuenta es que los índices agrupados deben tener una clave única (una columna de identidad que recomendaría) como primera columna. Básicamente, ayuda a su inserción de datos al final del índice y no causa muchas divisiones de IO y páginas de disco.

En segundo lugar, si está creando otros índices en sus datos y están construidos inteligentemente, serán reutilizados.

por ejemplo, imagine que busca una tabla en tres columnas

estado, condado, zip.

  • a veces busca por estado solamente.
  • a veces busca por estado y condado.
  • con frecuencia busca por estado, condado, código postal.

Luego, un índice con estado, condado, código postal. se usará en las tres búsquedas.

Si busca por zip solo bastante, entonces el índice anterior no será utilizado (por SQL Server de todos modos) ya que zip es la tercera parte de ese índice y el optimizador de consultas no verá ese índice como útil.

A continuación, podría crear un índice solo en Zip que se usaría en esta instancia.

Supongo que la respuesta que está buscando es que depende de sus cláusulas where de sus consultas de uso frecuente y también de las de su grupo.

El artículo ayudará mucho. 🙂

Sí. Te recomiendo que revises los artículos de Kimberly Tripp sobre indexación .

Si un índice está “cubriendo”, entonces no hay necesidad de usar nada más que el índice. En SQL Server 2005, también puede agregar columnas adicionales al índice que no son parte de la clave, lo que puede eliminar viajes al rest de la fila.

Tener múltiples índices, cada uno en una sola columna puede significar que solo se usa un índice en absoluto. Tendrá que consultar el plan de ejecución para ver qué efectos ofrecen los diferentes esquemas de indexación.

También puede usar el asistente de ajuste para ayudar a determinar qué índices harían que una determinada consulta o carga de trabajo obtuviera el mejor rendimiento.

El índice de varias columnas se puede usar para consultas que hacen referencia a todas las columnas:

 SELECT * FROM TableName WHERE Column1=1 AND Column2=2 AND Column3=3 

Esto se puede buscar directamente utilizando el índice de varias columnas. Por otro lado, se puede utilizar como máximo uno de los índices de una sola columna (tendría que buscar todos los registros que tengan Columna1 = 1, y luego verificar Columna2 y Columna3 en cada uno de ellos).

Un elemento que parece haberse perdido es la transformación de estrellas. Los operadores de Intersección de índice resuelven el predicado calculando el conjunto de filas afectadas por cada uno de los predicados antes de que se realice cualquier E / S en la tabla de hechos. En un esquema en estrella indexaría cada clave de dimensión individual y el optimizador de consultas puede resolver qué filas seleccionar mediante el cálculo de intersección del índice. Los índices en columnas individuales brindan la mejor flexibilidad para esto.

Si tiene consultas que utilizarán con frecuencia un conjunto de columnas relativamente estáticas, la creación de un único índice de cobertura que las incluya a todas mejorará el rendimiento de forma espectacular.

Al colocar varias columnas en su índice, el optimizador solo tendrá que acceder a la tabla directamente si una columna no está en el índice. Los uso mucho en data warehousing. La desventaja es que hacer esto puede costar muchos gastos generales, especialmente si los datos son muy volátiles.

Crear índices en columnas individuales es útil para las operaciones de búsqueda que se encuentran con frecuencia en los sistemas OLTP.

Debería preguntarse por qué indexa las columnas y cómo se usarán. Ejecute algunos planes de consulta y vea cuándo se está accediendo a ellos. El ajuste del índice es tanto instinto como ciencia.

El libro de Lahdenmaki y Leach, “Relational Database Index Design and the Optimizers”, introduce un sistema de tres estrellas para clasificar qué tan adecuado es un índice para una consulta.

  1. El índice gana una estrella si coloca filas relevantes adyacentes entre sí
  2. una segunda estrella si sus filas están ordenadas en el orden que la consulta necesita
  3. una estrella final si contiene todas las columnas necesarias para la consulta

Cree un índice múltiple en columnas, esta estrategia de indexación a menudo se produce cuando las personas dan consejos vagos pero con autoridad, como “crear índices en las columnas que aparecen en la cláusula WHERE”. Este consejo es muy incorrecto. Esto dará como resultado índices de una estrella en el mejor de los casos. Estos índices pueden ser muchos órdenes de magnitud más lentos que los índices verdaderamente óptimos. A veces, cuando no se puede diseñar un índice de tres estrellas, es mucho mejor ignorar la cláusula WHERE y prestar atención al orden de fila óptimo o crear un índice de cobertura en su lugar.

    Intereting Posts