¿Es malo tener un espacio de índice mayor que el espacio de datos?

A menudo necesito ejecutar consultas en tablas grandes que no tienen el índice correcto. Entonces le pido al DBA que cree dicho índice. Lo primero que hace es mirar las estadísticas de la tabla y ver el tamaño del espacio del índice.

A menudo me decía que buscara una solución alternativa porque "el índice ya es más grande que la tabla". Siente que el índice tiene que ser más pequeño que los datos, porque me dijo "¿alguna vez has visto el índice en un libro? Es mucho más pequeño que el libro en sí, y así debería ser un índice de tabla".

No creo que su filosofía sea correcta, pero no puedo desafiarlo porque es un DBA líder y yo soy un desarrollador. Creo que si una consulta necesita un índice, el índice solo debe crearse, en lugar de encontrar "soluciones" que solo hagan SP ilegibles e imposibles de mantener.

Estoy seleccionando solo las columnas requeridas. El problema es que estoy filtrando por fecha, por lo que el motor necesariamente hará un escaneo de la tabla para que coincida con las columnas. La consulta se ejecuta una vez al día, por la noche, para recopilar estadísticas, pero tarda 15 minutos en ejecutarse (tenemos otra regla estricta y rápida: ningún procedimiento debería tomar más de 3 minutos).

El DBA me mostró las estadísticas del índice. Había alrededor de 10 índices en esa tabla, de los cuales solo se usaron 6 (las estadísticas mostraron cero golpes a 4 de ellos). Este es un sistema grande con más de 20 desarrolladores participando. Los índices se crearon por cualquier motivo, y probablemente ya no se usan.

Estamos obligados a admitir SQL Server 2008, ya que en eso se ejecutan los DB de prueba. Pero todos los clientes están en 2014 y 2016.

Piense en el diseño de índice como un interruptor deslizante. Puede mover esta perilla de interruptor de triángulo rojo a cualquier lugar a lo largo de la línea que desee:

Por lo general, no lo mido en términos de tamaño, generalmente pienso en términos de cantidad de índice, pero el tamaño también estaría bien.

Parece que su DBA piensa que el cambio está demasiado hacia la derecha, que ha agregado demasiados índices y que las eliminaciones / actualizaciones / inserciones funcionan demasiado lentamente.

En lugar de discutir sobre dónde está el cambio, intente preguntarle sobre los problemas de rendimiento que tiene debido a la gran cantidad de índices. Tal vez sus usuarios se quejan de la velocidad de eliminación / actualización / inserción, o está viendo esperas de bloqueo, o está teniendo dificultades para hacer una copia de seguridad de la base de datos debido a su tamaño.

Mi punto de partida suele ser 5 y 5: alrededor de 5 índices por tabla, con alrededor de 5 o menos campos por índice. No hay nada mágico en ese número, solo proviene del hecho de que tengo 5 dedos en cada mano, por lo que es fácil levantar mis manos y explicar la regla.

Es posible que necesite tener muchos MENOS índices que 5 cuando su carga de trabajo está muy sesgada hacia las operaciones de eliminación / actualización / inserción, y no tiene suficiente potencia de hardware para mantenerse al día.

Es posible que pueda tener muchos MÁS índices cuando su carga de trabajo es principalmente de solo lectura o cuando invierte mucho en hardware (como almacenar en caché toda la base de datos en la memoria y tener todo el almacenamiento de estado sólido debajo de ella).

Además, el deseo de tener más de "The Ozar 5" índices en una tabla probablemente indica que tiene muchos tipos diferentes de consultas de lectura pesada en la tabla.

Lo que probablemente indica que podría beneficiarse de un índice de almacén de columnas agrupado o no agrupado en la tabla.

En lugar de tener el índice óptimo para cada una de las N rutas de acceso diferentes, un almacén de columnas le brinda un escaneo súper rápido y la capacidad de omitir columnas y segmentos de fila innecesarios. Por lo tanto, puede tener una pequeña cantidad de índices BTree para transacciones súper críticas y recurrir al almacén de columnas para todo lo demás.

Los índices del almacén de columnas están diseñados para funcionar en cargas de trabajo pesadas de OLTP con SQL Server 2016+. Consulte la documentación para el análisis operativo en tiempo real .

Me gusta la respuesta de Brents y la he votado. Sin embargo, me gustaría agregar otra perspectiva. He trabajado como usuario, desarrollador y DBA y siento que las opiniones no son relevantes. Creo que depende del usuario (o parte interesada) decidir cómo se realiza una consulta y cuánto tiempo lleva obtener resultados. Depende del desarrollador y del DBA trabajar juntos para que esto suceda.

Si el puesto de DBA en su empresa está "a cargo" de este tema, pueden analizar su consulta y hacer sugerencias sobre un mejor diseño de la consulta o responder por el rendimiento.

Si la estructura de consulta y / o datos no se puede modificar para lograr el objetivo, creo que se reduce a tres opciones.

1. Recuperación lenta de datos
2. Actualización lenta de datos
3. Más recursos de hardware $$$$

Por supuesto, cada situación tiene muchas variables que dependen de múltiples factores comerciales y tecnológicos, pero creo que las tres opciones se aplican a la mayoría, si no a todos los casos.

Parece demasiado estricto para prohibir índices> tabla. Si su tabla rara vez cambia (o cambia de noche cuando no hay mucha competencia por los recursos) y se le consulta mucho de muchas maneras diferentes, se pueden justificar muchos índices grandes. Los DBA también deben tener cuidado de no meter la nariz donde no pertenece. Si le da a usted / a su sistema un límite de gigabytes, no debería importarle demasiado cómo se usa ese espacio. Si está sobrecargado de trabajo, este podría ser el motivo.

Sin embargo, hay muchas cosas a considerar:

• Muchos índices hacen que las inserciones / actualizaciones / eliminaciones sean más lentas. Entonces, si su tabla cambia mucho, tenga cuidado de no hacer demasiados.
• El espacio también puede ser un problema. No solo porque los gigabytes cuestan dinero (no mucho en la actualidad), sino también por el tiempo, ya que la copia de seguridad será más lenta (dependiendo de cómo se realice la copia de seguridad).
• Las bases de datos más serias se pueden monitorear para encontrar índices que rara vez o nunca se usan. Considere dejar caer algunos de ellos.
• A veces cree que necesita un índice, pero cuando examina su consulta más de cerca, puede ajustarse y reescribirse de manera diferente con el mismo resultado y sin la necesidad del índice. Use el plan de explicación para ver si el índice se usa o no.
• A veces, las últimas columnas se pueden eliminar de un índice de varias columnas sin mucho impacto en el rendimiento. Y a veces esto incluso puede hacer que las consultas sean más rápidas porque el espacio de almacenamiento del índice es más pequeño y una mayor parte del índice se mantendrá / almacenará en la memoria caché en cualquier momento dado.
• Los índices basados ​​en funciones pueden reemplazar a los normales para ahorrar más espacio. Ejemplo: en lugar de consultar el apellido completo, consulte también las dos primeras letras (where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput> ) y create index i on customers(substr(surname,1,2)). Esto podría ser lo suficientemente rápido y su índice será más pequeño.
• Las bases de datos admiten diferentes tipos de índices. Algunos tipos usan menos espacio que otros. ¿Quizás algunos de sus índices se pueden convertir a un tipo que consuma menos espacio? Asegúrese de comprender primero los diferentes tipos de índices y para qué situaciones son buenos y malos.
• Si un trabajo por lotes infrecuente es lo único que necesita un índice específico, considere crear ese índice solo para ese trabajo por lotes y colóquelo después.