Solución:
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: Uso de índices de cobertura para mejorar el rendimiento de las consultas.
Si todas las columnas solicitado en el select lista de consulta, son disponible en el índice, el motor de consultas no tiene que 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 cubre la consulta. Entonces, la consulta se llama consulta de cobertura y el índice es un índice de cobertura.
Un índice agrupado siempre puede cubrir una consulta, si las columnas de la lista de selección son de la misma tabla.
Los siguientes enlaces pueden resultar útiles si no está familiarizado con los conceptos de indexación:
- Excelente video sobre las ventajas y desventajas de indexar y cubrir consultas e índices.
- Índices en SQL Server
Un índice de cobertura es un Non-Clustered índice. Tanto los índices agrupados como los no agrupados utilizan la estructura de datos B-Tree para mejorar la búsqueda de datos, la diferencia es que en las hojas de un índice agrupado un registro completo (es decir, una 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.
Sin embargo, para un índice no agrupado, hay dos posibilidades: o la tabla ya tiene un índice agrupado o no:
Como muestran los dos diagramas, dichos índices no agrupados no proporcionan un buen rendimiento porque no pueden encontrar el valor favorito (es decir, Lname) únicamente en el árbol B. En su lugar, tienen que realizar un paso de búsqueda adicional (búsqueda de clave o de RID) para encontrar el valor de Lname. Y, aquí es donde aparece el índice cubierto en la pantalla. Aquí, el índice no agrupado en ID cubre 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.
