Es difícil decir esto de manera más sucinta que Brad McGehee, MVP de SQL Server:
Como regla general, cada tabla debe tener un índice agrupado. En general, pero no siempre, el índice agrupado debe estar en una columna que aumenta de forma monótona, como una columna de identidad o alguna otra columna donde el valor aumenta, y es única. En muchos casos, la clave principal es la columna ideal para un índice agrupado.
BOL se hace eco de este sentimiento:
Con pocas excepciones, cada tabla debe tener un índice agrupado.
Las razones para hacer esto son muchas y se basan principalmente en el hecho de que un índice agrupado ordena físicamente sus datos almacenados .
-
Si su índice agrupado está en una sola columna aumenta de forma monótona, las inserciones se producen en orden en su dispositivo de almacenamiento y no se producirán divisiones de página.
-
Los índices agrupados son eficientes para encontrar una fila específica cuando el valor indexado es único, como el patrón común de seleccionar una fila según la clave principal.
-
Un índice agrupado a menudo permite consultas eficientes en columnas que a menudo se buscan por rangos de valores (
between,>, etc.). -
La agrupación en clústeres puede acelerar las consultas en las que los datos normalmente se ordenan por una columna o columnas específicas.
-
Un índice agrupado se puede reconstruir o reorganizar a pedido para controlar la fragmentación de la tabla.
-
Estos beneficios incluso se pueden aplicar a las vistas.
Es posible que no desee tener un índice agrupado en:
-
Columnas que tienen cambios de datos frecuentes, ya que SQL Server debe reordenar físicamente los datos almacenados.
-
Columnas que ya están cubiertas por otros índices.
-
Claves anchas, ya que el índice agrupado también se usa en búsquedas de índices no agrupados.
-
Columnas GUID, que son más grandes que las identidades y también valores efectivamente aleatorios (no es probable que se ordenen), aunque
newsequentialid()podría usarse para ayudar a mitigar el reordenamiento físico durante las inserciones. -
Una rara razón para usar un montón (tabla sin un índice agrupado) es si siempre se accede a los datos a través de índices no agrupados y se sabe que el RID (identificador de fila interno de SQL Server) es más pequeño que una clave de índice agrupado.
Debido a estas y otras consideraciones, como las cargas de trabajo de su aplicación particular, debe seleccionar cuidadosamente sus índices agrupados para obtener el máximo beneficio para sus consultas.
También tenga en cuenta que cuando crea una clave principal en una tabla en SQL Server, por defecto creará un índice agrupado único (si aún no tiene uno). Esto significa que si encuentra una tabla que no tiene un índice agrupado, pero tiene una clave principal (como deberían tener todas las tablas), un desarrollador había tomado previamente la decisión de crearla de esa manera. Es posible que desee tener una razón convincente para cambiar eso (de las cuales hay muchas, como hemos visto). Agregar, cambiar o eliminar el índice agrupado requiere volver a escribir toda la tabla y cualquier índice no agrupado, por lo que esto puede llevar algún tiempo en una tabla grande.
