2009-03-04 37 views

Respuesta

35

Un índice de cobertura es aquel 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: Using Covering Indexes to Improve Query Performance.

+9

Vale la pena señalar que el artículo se ha vinculado a se refiere a una cubierta de consulta. Parecen definirlo como una consulta que selecciona columnas que se INCLUYERON en un índice de cobertura, es decir, un índice que no es el índice de agrupación en clúster, que tiene los valores de columna repetidos en su nodo de hoja. También vale la pena señalar que un índice de cobertura tiene una penalización obvia de rendimiento para INSERT/UPDATE. –

+0

@ChrisMoschini, entonces ¿qué es una [consulta cubierta] (http://sqlmag.com/database-performance-tuning/covered-query-vs-covering-index)? Igual que la consulta de cobertura? – Pacerier

+1

@Pacerier Sí, son lo mismo. –

2

Una consulta de cobertura es donde todos los predicados se pueden combinar utilizando los índices en las tablas subyacentes.

Este es el primer paso para mejorar el rendimiento de sql bajo consideración.

8

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

Una consulta se realiza 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 montón, por lo que deben introducirse menos páginas en la memoria para satisfacer el consulta. Tienen más filas por página porque solo parte de la fila de la tabla es parte de la fila del índice.

A que cubre el índice 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 una, mientras que al mismo tiempo no ser un índice de cobertura con respecto a la consulta B.

+0

Dado que un aspecto significativo del rendimiento es "¿cuántas páginas debo traer a la memoria para devolver el conjunto completo de resultados?", ¿Significa eso que ** una consulta 'LIMIT 1' no se beneficia de la optimización de cobertura? ** En la mayoría de los casos, tomar un solo registro requerirá solo una sola lectura de página (ignorando los casos extremos como el almacenamiento fuera de la página o las tablas realmente anchas). Incluso con una consulta no cubierta. – Birchlabs

5

Aquí es an article in devx.com que dice:

Creación de un índice no agrupado que contiene todas las columnas utilizadas en una consulta SQL, una técnica llamada índice que cubre

sólo puedo suponer que una consulta cubiertaes una consulta que tiene un índice que cubre todas las columnas de su recordset devuelto. Una advertencia: el índice y la consulta tendrían que crearse para permitir que el servidor SQL realmente infiera de la consulta que el índice es útil.

Por ejemplo, una combinación de una tabla en sí misma no podría beneficiarse de este índice (en función de la inteligencia del planificador de ejecución de la consulta SQL):

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

Asumamos que hay un índice en PersonID,ParentID,Name - este sería un índice de cobertura de una consulta como:

SELECT PersonID, ParentID, Name FROM MyTable 

embargo, una consulta como esta:

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

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

En su lugar, está la construcción de una condición basada en dos columnas - PersonID y ParentID (que deja fuera Name) y luego usted está pidiendo todos los registros, con las columnas PersonID, Name. De hecho, dependiendo de la implementación, el índice podría ayudar a la última parte. Pero para la primera parte, es mejor tener otros índices.

19

Si todas las columnas solicitados en la lista de consulta select, son disponible en el índice, entonces el motor de consulta no tiene que buscar la mesa de nuevo lo que puede aumentar significativamente el rendimiento de la consulta. Como todas las columnas solicitadas están disponibles en el índice, el índice cubre la consulta. Por lo tanto, 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 pertenecen a la misma tabla.

Los siguientes enlaces pueden ser útiles, si usted es nuevo a los conceptos de índice:

2

un índice de cobertura es la que le da a cada columna necesaria y en el que El servidor SQL no tiene un salto al índice agrupado para encontrar cualquier columna. Esto se logra usando un índice no agrupado y usando la opción INCLUDE para cubrir las columnas. Las columnas sin clave se pueden incluir solo en índices no agrupados. Las columnas no se pueden definir tanto en la columna clave como en la lista INCLUDE. Los nombres de columna no se pueden repetir en la lista INCLUDE. Las columnas sin clave pueden soltarse de una tabla solo después de que el índice sin clave se descarta primero. Please see details here

1

Cuando simplemente recordé que un Índice Agrupado consiste en una lista ordenada por no 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), 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 ningún otro índice "cubriendo". La falta causará un operador de búsqueda de índice agrupado en el plan de ejecución propuesto, donde el valor buscado se encuentra 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 forma, 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 agrupamiento de una sola columna y un argumento con un valor escalar en la clave de agrupamiento, el operador de búsqueda de índice agrupado seguirá utilizándose, incluso si ya hay un índice de cobertura en una segunda columna en el tabla sin un índice

6

Un índice de cobertura es un índice no agrupado. Tanto los índices agrupados como los no agrupados usan B-Trees para mejorar la búsqueda de datos, la diferencia es que en las hojas de un índice agrupado se almacena físicamente un registro completo (es decir, una fila), pero este no es el caso de Índices no agrupados.

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

enter image description here

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

enter image description here

Como los dos diagramas show, estos índices no agrupados no proporcionan un buen rendimiento, porque no pueden encontrar el valor favorito (es decir, Lname) únicamente del árbol B. En su lugar, tienen que hacer un paso adicional de búsqueda (búsqueda clave o RID) para encontrar el valor de Lname. Y, , aquí es donde aparece el índice cubierto en la pantalla. Aquí, el índice no agrupado de ID codifica el valor de Lname junto a él en las hojas del árbol B y ya no hay necesidad de ningún tipo de búsqueda.

enter image description here

Cuestiones relacionadas