Mi pregunta es, si un índice no agrupado indexa más columnas que las utilizadas por una consulta, ¿eso se traduce en una ejecución de consulta más lenta que un índice que coincide exactamente con la consulta?
No, tener más columnas no ralentiza el tiempo de consulta para las consultas que usan las primeras 1, 2, n columnas en el índice. Dicho esto, si tiene poca memoria, la carga del índice en la memoria puede hacer que otras cosas queden fuera de la memoria y ralentizar la consulta, pero si tiene mucha memoria, esto no debería ser un problema.
A medida que aumenta el número de consultas distintas, también lo hace el número de permutaciones de columnas utilizadas en sus cláusulas WHERE. No estoy seguro acerca de las compensaciones entre tener muchos índices con un pequeño número de columnas (uno para cada consulta) versus menos índices en más columnas.
Primero debe agregar los campos únicos consultados con más frecuencia en los índices. Menos índices con muchas columnas pueden no darle lo que desea.
por ejemplo, si usted tiene un índice con las siguientes columnas:
- ColumnA
- ColumnB
- ColumnC
- ColumnD
- ColumnE
- ColumnF
en ese orden, las consultas que filtran contra ColumnA, ColumnB, ColumnC, ColumnD ... usarán el índice, pero si solo está consultando ColumnE o ColumnF, no usará el índice.
Adoptar un enfoque diffferent si tiene seis índices en una sola tabla, cada uno con una sola columna
- Índice1 - ColumnA
- índice 2 - ColumnB
- Index3 - ColumnC
- Index4 - ColumnD
- Index5 - ColumnE
- Index6 - ColumnF
En este caso, solo uno de esos 6 índices se utilizará para cualquier consulta.
Además, si el índice contiene un valor que no es muy selectivo, es posible que no lo ayude. Por ejemplo, si tiene una columna llamada GENDER que puede contener los siguientes valores (masculino, femenino y desconocido), probablemente no le ayude a incluir esta columna en el índice. Cuando se ejecuta la consulta, SQL Server puede determinar que la columna no es lo suficientemente selectiva y solo asumir que una exploración de tabla completa sería más rápida.
Hay muchas maneras de averiguar qué índices está utilizando la consulta, pero un enfoque que uso es mirar los índices que nunca se utilizan. Ejecute la siguiente consulta en su base de datos y descubra si realmente se están utilizando los índices que cree que se están utilizando.
SELECT iv.table_name,
i.name AS index_name,
iv.seeks + iv.scans + iv.lookups AS total_accesses,
iv.seeks,
iv.scans,
iv.lookups,
t.indextype,
t.indexsizemb
FROM (SELECT i.object_id,
Object_name(i.object_id) AS table_name,
i.index_id,
SUM(i.user_seeks) AS seeks,
SUM(i.user_scans) AS scans,
SUM(i.user_lookups) AS lookups
FROM sys.tables t
INNER JOIN sys.dm_db_index_usage_stats i
ON t.object_id = i.object_id
GROUP BY i.object_id,
i.index_id) AS iv
INNER JOIN sys.indexes i
ON iv.object_id = i.object_id
AND iv.index_id = i.index_id
INNER JOIN (SELECT sys_schemas.name AS schemaname,
sys_objects.name AS tablename,
sys_indexes.name AS indexname ,
sys_indexes.type_desc AS indextype ,
CAST(partition_stats.used_page_count * 8/1024.00 AS DECIMAL(10, 3)) AS indexsizemb
FROM sys.dm_db_partition_stats partition_stats
INNER JOIN sys.indexes sys_indexes
ON partition_stats.[object_id] = sys_indexes.[object_id]
AND partition_stats.index_id = sys_indexes.index_id
AND sys_indexes.type_desc <> 'HEAP'
INNER JOIN sys.objects sys_objects
ON sys_objects.[object_id] = partition_stats.[object_id]
INNER JOIN sys.schemas sys_schemas
ON sys_objects.[schema_id] = sys_schemas.[schema_id]
AND sys_schemas.name <> 'SYS') AS t
ON t.indexname = i.name
AND t.tablename = iv.table_name
--WHERE t.IndexSizeMB > 200
WHERE iv.seeks + iv.scans + iv.lookups = 0
ORDER BY total_accesses ASC;
lo general localizar a índices que no se hayan usado, o no se han utilizado varios meses después de reiniciar SQL Server, y determinar si se deben eliminar o no. A veces, demasiados índices pueden ralentizar SQL Server averiguando la mejor ruta para ejecutar una consulta, y eliminar los índices no utilizados puede acelerar ese proceso.
Espero que esto ayude a dar sentido a sus índices.
¡Gran pregunta! Esta no es realmente una respuesta, pero Kimberly Tripp ha escrito varios artículos brillantes sobre indexación de SQL que tal vez quiera consultar. Aquí hay solo uno: http://www.sqlskills.com/blogs/kimberly/Default.aspx#p4 – Yuck