La importancia de los índices clustered

Una de las recomendaciones sobre rendimiento de SQL Server más simple y útil es que 'toda tabla debe tener un índice clustered'. Esto no es 100% cierto y como casi toda norma tiene sus excepciones, pero son pocas.

Las ventajas de tener un índice clustered son varias pero cabe destacar algunos de los motivos por los que influyen en el rendimiento (simplificando algo el tema dicho sea de paso):

  • Los registros están fisicamente ordenados según el índice clustered de la tabla (solo puede haber uno por tabla). Esto hace que el acceso a rangos de registros utilizando los campos del índice como filtro sea extremadamente rápido. Tambien es extremadamente rápida la ordenación y el filtrado sobre un índice clustered. Por lo tanto, debemos elegir indicés clustered adecuados para soportar este tipo de consultas, sobre todo cuando se realicen con mucha frecuencia.
  • El resto de índices de una tabla que tenga un índice clustered se apoyan en este índice para guardar su información. Por ello debemos tratar elegir índices clustered sobre campos o combinaciones de campos del menor tamaño posible.
  • Al final de un índice clustered se encuentra fisicamente los datos de los campos que forman parte del índice, de manera que si nuestra consulta solo necesita campos que se encuentran dentro del índice clustered no necesitará hacer ninguna lectura adicional una vez buscados los registros usando el índice.

A la hora de elegir un índice clustered debemos tener en cuenta las siguientes recomendaciones:

  • Se sea usado por el mayor número posible de consultas, sobre todo por aquellas que devuelven un rango de registros seleccionados por el índice o se ordenan o agrupan por los campos del índice. También se benefician aquellas consultas que realizan JOINs sobre los campos cubiertos por el índice.
  • No debemos elegir campos que cambian con mucha frecuencia o que almacenan mucha información. Cuanto más pequeño en cuanto a tamaño de los campos sea nuestro índice clustered mejor. Las columnas autonuméricas suelen ser unas exelentes candidatas a índice clustered. Por defecto las claves primarias son índices clustered, suele ser una buena opción, salvo que la clave primaria cambie con mucha frecuencia.
  • Cuanto más exclusivos sean los valores del índice clustered mejor. La situación ideal es que los valores combinados de los campos que componen el índice sean únicos.

Por último os dejo un pequeño script T-SQL que nos dice que tablas de nuestra base de datos no tienen un índice clustered, y que por lo tanto requieren nuestra atención:

select t.name from sys.tables t
where t.name not in
(
      select t.name from sys.tables t
      join sys.indexes i
      on t.object_id = i.object_id
      where
            t.type = 'U' --Solo nos interesan las tablas de usuario
            and i.type = '1' --1 == Índice clustered
)

Published 22/1/2007 14:04 por Rodrigo Corral
Archivado en:
Comparte este post:
http://geeks.ms/blogs/rcorral/archive/2007/01/22/la-importancia-de-los-iacute-ndices-clustered.aspx

Comentarios

# Usando subconsultas en SQL, para reducir la complejidad de nuestros queries

Siempre que tengamos consultas complejas, donde intervienen varias tablas y además hay varios filtros,...

Friday, February 16, 2007 11:43 PM por Sergio Tarrillo's Blog -> enhancements

# Usando subconsultas en SQL, para reducir la complejidad de nuestros queries

Siempre que tengamos consultas complejas, donde intervienen varias tablas y además hay varios filtros,

Friday, February 16, 2007 11:43 PM por SergioTarrillo's RichWeblog

# ¿A más procesadores consulta más lenta?

Que paradojas tiene la informática... tendemos a suponer que tener más procesadores tiende ha hacer que

Tuesday, March 20, 2007 1:03 AM por La masa, el ladrillo, la bota, el bocadillo...