Si una base de datos solo tiene una inserción, ¿es malo indexar todas las combinaciones posibles de columnas?


23

Estoy trabajando en un sistema de informes que requerirá grandes consultas de selección, pero se basa en una base de datos que solo se llena una vez. El sistema de administración de bases de datos es Microsoft SQL Server 2017. Probablemente haya una mejor manera de diseñar un sistema como este, pero abordemos esto teóricamente.

Teóricamente hablando:

  1. Si tenemos una base de datos muy grande (más de 150 millones de filas en varias tablas)
  2. Y podemos suponer que la base de datos solo se completará una vez.

¿Podría indexar cada combinación de columna posible tener un impacto negativo en el rendimiento de una consulta de selección?


44
Cada combinación posible no es práctica la mayoría de las veces. Un enfoque más sensato es indexar manualmente pero con mucha generosidad. Eso definitivamente puede tener sentido.
Usr

12
Sugiero volver a redactar su título o su texto en negrita para que sean consistentes. De un vistazo estaba confundido por la respuesta más votada "Sí"
aaaaaa

150 millones de filas es grande para una sola tabla, pero no es grande para una base de datos. Hablando en términos prácticos, los sistemas de informes solo usan un pequeño subconjunto de posibles combinaciones de columnas, es mejor enfocarse en las combinaciones de teclas al menos inicialmente, y luego volverse más complejas solo cuando sea necesario.
pojo-guy

Respuestas:


36

Sí, influirá en el tiempo de compilación del plan inicial ya que el optimizador tendrá muchas rutas de acceso adicionales a los datos a considerar.

Dado que está en SQL Server 2017, cargando una vez y ejecutando informes, ¿por qué no usar un índice de almacén de columnas en su lugar?

Esa parece ser la solución ideal para su necesidad de indexar todas las combinaciones posibles de columnas.

Índices de almacén de columnas: descripción general


Columnstore es donde yo también iría, pero me pregunto ... ¿el optimizador no funciona al contrario de lo que describiste? Quiero decir, en lugar de escanear índices disponibles y "preguntarme" cuál de ellos podría ser útil, ¿no examina la consulta y "piensa" en un índice perfecto para esa consulta, y luego comprueba si existe? (Si no es así, se genera un mensaje de índice faltante). Si estoy en lo cierto (no sé, solo adivinando), incluso si hay miles de índices, no debería ser mucho más tiempo que tener solo varios de ellos.
Limonka

26

Si tiene N columnas en una tabla, cada combinación de columnas posible es 2 ^ N-1 (eliminando el conjunto vacío). Para 10 columnas que significarían 1023 índices, para 20 columnas terminamos con la friolera de 1048575 índices. La mayoría de los índices nunca se utilizarán, pero el optimizador deberá tenerlos en cuenta. Es posible que el optimizador elija un índice subóptimo en lugar de uno mejor. No tomaría el camino de generar todo tipo de índices, en lugar de tratar de averiguar qué índices serían realmente beneficiosos.

EDITAR el número corregido de índices posibles

Como Jeff señala, es incluso peor que 2 ^ N (conjunto de potencia) ya que (3,2,1) es claramente diferente de (1,2,3). Para N columnas podemos elegir la primera posición en un índice que contiene todas las columnas en N formas. Para la segunda posición en N-1, etc. ¡Por lo tanto, terminamos con N! diferentes índices de tamaño completo. Ninguno de estos índices está incluido en otro índice de este conjunto. Además, no podemos agregar otro índice más corto para que no esté cubierto por ningún índice completo. El número de índices es, por lo tanto, N !. ¡El ejemplo para 10 columnas, por lo tanto, se convierte en 10! = 3628800 índices y para 20 (rollroll) 2432902008176640000 índices. Este es un número ridículamente grande, si ponemos un punto para cada índice un mm por parte, tomará un haz de luz 94 días para pasar todos los puntos. Todos y todas, no ;-)


66
Peor aún: el orden de las columnas en el índice puede ser importante. Por lo tanto, obtienes un máximo de N! índices
Jeff

2
Pero no necesita índices que sean prefijos de otros índices.
Barmar

3
Es aun peor. Hay combinaciones ASC y DESC para cada índice.
ypercubeᵀᴹ

2
Y mucho peor, hay índices INCLUDE.
ypercubeᵀᴹ

2
Y una gran cantidad de índices parciales.
ypercubeᵀᴹ

7

No.

No es práctico indexar "todo", pero puede indexar "la mayoría" de él.

Aquí está la cosa. Si una tabla tiene Ncolumnas, entonces el número de índices posibles es N!. Digamos que una tabla tiene 10 columnas, entonces no solo tiene 10índices posibles, sino también 10!. Eso es ... 3,628,800 ... en una sola mesa. Eso es mucho espacio en disco, E / S de disco, caché y tiempos de búsqueda.

¿Por qué? Algunas razones:

  • Los índices de Lightwwight generalmente se almacenan en caché, algo que los hace encenderse rápidamente. Si tiene 3 millones de ellos, NO se almacenarán en caché.

  • El optimizador de SQL puede tomar mucho tiempo para decidir cuál es mejor usar, especialmente cuando se usan combinaciones.

  • El optimizador de SQL puede renunciar al uso del algoritmo integral e intentar un algoritmo heurístico. Esto puede ser "menos que óptimo". PostgreSQL, por ejemplo, tiene diferentes opciones para "consultas de tabla de menos de 8" y "consultas de tabla de más de 8".

  • Se supone que los índices son más ligeros que el montón. Si está indexando todo, entonces el índice se vuelve tan pesado como el montón ... algo que anula el propósito del índice.


¿No es el número 2 ^ 10? Cada columna se incluye o excluye de un índice dado. ¿Importa el orden?
RemcoGerlich

2
@RemcoGerlich sí, el orden importa.
ypercubeᵀᴹ

2

No, probablemente no tendrá un impacto negativo en las SELECTconsultas, pero

  • Causará un alto uso del disco.
  • Será enormemente aumentar los INSERTcostos.
  • La mayoría de sus índices nunca se utilizarán.
  • Muchas WHEREexpresiones de condición aún no usarán índices, principalmente las más complejas.
  • El recuento de los índices requeridos aumentará exponencialmente con el recuento de las columnas. Es decir, si tiene, por ejemplo, 8 columnas, necesita 256 índices para todas las combinaciones posibles.

Puede causar un problema total en el tiempo de compilación.
Erik Darling

@sp_BlitzErik ¿Crees que el ORM en la aplicación?
Peter dice reinstalar a Mónica el

No, mira mi respuesta.
Erik Darling

@sp_BlitzErik Wow, ¡qué bueno ver!
Peter dice reinstalar a Mónica el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.