Nuestro proyecto ejecuta una base de datos muy grande y muy complicada. Entonces, hace aproximadamente un mes, notamos que el espacio utilizado por las columnas indexadas que contenían valores nulos se estaba volviendo demasiado grande. Como respuesta a eso, escribí un script que buscaría dinámicamente en todos los índices de una sola columna que contengan más del 1% de los valores nulos, luego descartaría y volvería a crear esos índices como índices filtrados con la condición de que el valor NO fuera NULL. Esto eliminaría y recrearía cientos de índices en toda la base de datos y, por lo general, liberaría casi el 15% del espacio utilizado por toda la base de datos.
Ahora tengo dos preguntas sobre esto:
A) ¿Cuáles son las desventajas de usar índices filtrados de esta manera? Supongo que solo mejoraría el rendimiento, pero ¿hay algún riesgo de rendimiento involucrado?
B) Recibimos errores ( 'no se puede eliminar el índice XYZ porque no existe o no tiene permiso' ) al soltar y volver a crear los índices, aunque cuando se verificó después, todo había salido exactamente como se esperaba. ¿Cómo puede pasar esto?
¡Gracias por cualquier ayuda!
Editar: en respuesta a @Thomas Kejser
Hola y gracias, pero resulta que fue un desastre. En ese momento no entendíamos varias cosas como:
- Durante una consulta, SQLOS realiza planes de índice antes de determinar que no puede usar valores NULL para unir columnas de tabla. Es decir, realmente necesita tener un filtro de cláusula WHERE que se ajuste al índice para todos y cada uno de los índices filtrados utilizados en la consulta, o el índice no se utilizará en absoluto.
- Dejar caer y crear índices y actualizar de forma redundante sus estadísticas una vez más después aún puede no ser suficiente para producir los planes actualizados, lo que asumimos que lo harían. Parece que en algunos casos solo una carga de trabajo lo suficientemente alta obligará a SQL Server a reevaluar los planes.
- Hay algunas características exóticas de la funcionalidad del planificador de ejecución que son difíciles de determinar solo por el sentido común y la lógica. Incluso con miles de variaciones generadas por código subyacente de diferentes consultas, los índices aparentemente inútiles pueden ayudar en algunas estadísticas y planes de consulta que terminan siendo utilizados en consultas críticas.
Al final, estos cambios fueron revertidos. Por lo tanto, los índices filtrados son una herramienta poderosa, pero debe comprender realmente exactamente qué datos se obtienen de esas columnas. Donde los índices normales aparte de los problemas de espacio son bastante fáciles de aplicar, los índices filtrados representan soluciones muy personalizadas. Ciertamente no son un reemplazo para un índice regular, sino una extensión para ellos en esas circunstancias especiales que se requieren.
Respuestas:
Enfoque muy interesante. Mi voto a favor de la creatividad.
Dado que recuperó el espacio, supongo que los índices originales ya no están en su lugar. Las desventajas de los índices filtrados son:
En términos prácticos, esto significa que debe ser extremadamente cuidadoso con los índices filtrados ya que a menudo darán como resultado planes de consulta horribles. No iría tan lejos como para llamarlos inútiles, pero los veo como una adición a los índices tradicionales, no como un reemplazo (como está tratando de hacer).
fuente
Thomas Kejser responde a este tema más arriba.
Solo pensé en agregar 2 centavos.
He visto que solo se usan algunos índices filtrados (que se muestran en el plan de ejecución) cuando coincide exactamente con la cláusula where en su consulta como el where en el índice filtrado.
¿Has intentado usar vistas indexadas ? columnas dispersas ?
Creo que, en la medida en que solo tenga uniones internas, puede crear una vista indexada que contenga las cláusulas where de sus índices filtrados y luego puede usar la vista en su lugar.
Podría haber más de una vista. Pero al igual que con los índices no agrupados, demasiados retrasarán su escritura.
Según mi experiencia, tendría buenas ganancias en lectura, pero tendría que monitorear las escrituras (inserciones y actualizaciones) especialmente si las tablas están involucradas en la replicación.
Sin embargo, como entiendo que su principal preocupación es,
the null valuespor lo tanto, le sugeriría columnas SPARSE en sus índices .Las columnas dispersas son especialmente apropiadas para índices filtrados.
Como he anunciado columnas dispersas, no me sentiría bien si no le dijera también sobre sus limitaciones:
Como resultado de esto
Considere el> ejemplo de una tabla que tiene 600 columnas dispersas de tipo bigint.
más detalles en el enlace de arriba, sin embargo, prefiero publicar aquí esta advertencia también:
El Motor de base de datos de SQL Server utiliza el siguiente procedimiento para lograr este cambio:
1: agrega una nueva columna a la tabla en el nuevo tamaño y formato de almacenamiento.
2: para cada fila de la tabla, actualiza y copia el valor almacenado en la columna anterior a la nueva columna.
3 - Elimina la columna anterior del esquema de la tabla.
4 - Reconstruye la tabla (si no hay índice agrupado) o reconstruye el índice agrupado para reclamar el espacio utilizado por la columna anterior.
fuente