Pregunta

¿Puede explicar los conceptos y la relación entre los índices de cobertura y las consultas cubiertas en el servidor SQL de Microsoft?

¿Fue útil?

Solución

Un índice de cobertura es uno que puede satisfacer todas las columnas solicitadas en una consulta sin realizar una búsqueda adicional en el índice agrupado.

No existe una consulta de cobertura.

Eche un vistazo a este artículo de Simple-Talk: Uso de índices de cobertura para mejorar el rendimiento de las consultas .

Otros consejos

Si todas las columnas solicitadas en la lista de consulta select , están disponibles en el índice , entonces el motor de consultas no tiene para volver a buscar en la tabla, lo que puede aumentar significativamente el rendimiento de la consulta. Dado que todas las columnas solicitadas están disponibles en el índice, el índice está cubriendo la consulta. Entonces, la consulta se denomina consulta de cobertura y el índice es un índice de cobertura.

Un índice agrupado siempre puede cubrir una consulta, si las columnas en la lista de selección son de la misma tabla.

Los siguientes enlaces pueden ser útiles, si eres nuevo en los conceptos de indexación:

Un índice de cobertura es un índice no agrupado . Tanto los índices agrupados como los no agrupados utilizan la estructura de datos del árbol B para mejorar la búsqueda de datos, la diferencia es que en las hojas de un índice agrupado, todo un registro (es decir, fila) se almacena físicamente allí mismo, pero este no es el caso para índices no agrupados. Los siguientes ejemplos lo ilustran:

Ejemplo: tengo una tabla con tres columnas: ID, Fname y Lname.

 introduce la descripción de la imagen aquí

Sin embargo, para un índice no agrupado, hay dos posibilidades: o la tabla ya tiene un índice agrupado o no:

 introduce la descripción de la imagen aquí

Como muestran los dos diagramas, estos índices no agrupados no proporcionan un buen rendimiento, porque no pueden encontrar el valor favorito (es decir, Lname) únicamente del B-Tree. En su lugar, tienen que realizar un paso de búsqueda adicional (ya sea clave o RID buscar) para encontrar el valor de Lname. Y, aquí es donde aparece el índice cubierto. Aquí, el índice no agrupado en la ID cubre el valor de Lname justo al lado en las hojas del árbol B y no hay necesidad para cualquier tipo de búsqueda más.

 introduce la descripción de la imagen aquí

Una consulta cubierta es una consulta en la que todas las columnas del conjunto de resultados de la consulta se extraen de índices no agrupados.

Se realiza una consulta en una consulta cubierta por la disposición juiciosa de los índices.

Una consulta cubierta suele ser más eficaz que una consulta no cubierta en parte porque los índices no agrupados tienen más filas por página que los índices agrupados o los índices de almacenamiento dinámico, por lo que es necesario llevar menos páginas a la memoria para satisfacer la consulta. . Tienen más filas por página porque solo una parte de la fila de la tabla forma parte de la fila del índice.

Un índice de cobertura es un índice que se utiliza en una consulta cubierta. No existe un índice que, en sí mismo, sea un índice de cobertura. Un índice puede ser un índice de cobertura con respecto a la consulta A, mientras que al mismo tiempo no es un índice de cobertura con respecto a la consulta B.

Aquí hay un artículo en devx.com que dice:

  

Creando un índice no agrupado que contiene todas las columnas utilizadas en una consulta SQL, una técnica llamada cobertura de índice

Solo puedo suponer que una consulta cubierta es una consulta que tiene un índice que cubre todas las columnas de su conjunto de registros devuelto. Una advertencia: el índice y la consulta deberían construirse de modo que el servidor SQL pueda inferir de la consulta que el índice es útil.

Por ejemplo, una combinación de una tabla en sí misma podría no beneficiarse de dicho índice (según la inteligencia del planificador de ejecución de consultas SQL):

PersonID ParentID Name
1        NULL     Abe
2        NULL     Bob
3        1        Carl
4        2        Dave

Supongamos que hay un índice en PersonID, ParentID, Name ; este sería un índice de cobertura para una consulta como:

SELECT PersonID, ParentID, Name FROM MyTable

Pero una consulta como esta:

SELECT PersonID, Name FROM MyTable LEFT JOIN MyTable T ON T.PersonID=MyTable.ParentID

Probablemente no se beneficiaría tanto, a pesar de que todas las columnas están en el índice. ¿Por qué? Porque realmente no le está diciendo que desea utilizar el índice triple de PersonID, ParentID, Name .

En cambio, está creando una condición basada en dos columnas: PersonID y ParentID (que deja de lado Name ) y luego usted ' re solicitando todos los registros, con las columnas PersonID, Name . En realidad, dependiendo de la implementación, el índice puede ayudar a la última parte. Pero para la primera parte, es mejor tener otros índices.

Una consulta de cobertura se encuentra en donde todos los predicados pueden coincidir usando los índices en las tablas subyacentes.

Este es el primer paso para mejorar el rendimiento del SQL que se está considerando.

un índice de cobertura es el que proporciona cada columna requerida y en el que el servidor SQL no tiene que volver al índice agrupado para encontrar ninguna columna. Esto se logra usando un índice no agrupado y usando la opción INCLUDE para cubrir columnas. Las columnas no clave solo se pueden incluir en índices no agrupados. Las columnas no se pueden definir tanto en la columna clave como en la lista INCLUIR. Los nombres de columna no se pueden repetir en la lista INCLUIR. Las columnas sin clave se pueden eliminar de una tabla solo después de que el índice sin clave se elimine primero. Vea los detalles aquí

Cuando simplemente recordé que un índice agrupado consiste en una lista ordenada sin clave de TODAS las columnas en la tabla definida, las luces se encendieron para mí. La palabra "grupo", entonces, se refiere al hecho de que hay un "grupo". de todas las columnas, como un grupo de peces en ese " punto caliente " ;. Si no hay un índice que cubra la columna que contiene el valor buscado (el lado derecho de la ecuación), entonces el plan de ejecución utiliza una Búsqueda de índice agrupado en la representación del Índice agrupado de la columna solicitada porque no encuentra la columna solicitada en ninguna otra " cubriendo " índice. La falta causará un operador de Búsqueda de índice agrupado en el Plan de ejecución propuesto, donde el valor buscado está dentro de una columna dentro de la lista ordenada representada por el Índice agrupado.

Entonces, una solución es crear un índice no agrupado que tenga la columna que contiene el valor solicitado dentro del índice. De esta manera, no es necesario hacer referencia al índice agrupado, y el optimizador debería poder enganchar ese índice en el plan de ejecución sin ninguna sugerencia. Sin embargo, si hay un predicado que nombra la clave de agrupación de una sola columna y un argumento para un valor escalar en la clave de agrupación, se seguirá utilizando el Operador de búsqueda de índice agrupado, incluso si ya hay un índice de cobertura en una segunda columna en el Tabla sin índice.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top