É difícil afirmar isso de forma mais sucinta do que o MVP do SQL Server Brad McGehee:
Como regra geral, cada tabela deve ter um índice clusterizado. Geralmente, mas nem sempre, o índice clusterizado deve estar em uma coluna que aumenta monotonicamente – como uma coluna de identidade ou alguma outra coluna em que o valor está aumentando – e é exclusivo. Em muitos casos, a chave primária é a coluna ideal para um índice clusterizado.
BOL ecoa esse sentimento:
Com poucas exceções, toda tabela deve ter um índice clusterizado.
As razões para fazer isso são muitas e baseiam-se principalmente no fato de que um índice clusterizado ordena fisicamente seus dados no armazenamento .
-
Se o índice clusterizado estiver em uma única coluna, aumentará monotonicamente, as inserções ocorrerão em ordem no dispositivo de armazenamento e as divisões de página não ocorrerão.
-
Os índices clusterizados são eficientes para localizar uma linha específica quando o valor indexado é exclusivo, como o padrão comum de selecionar uma linha com base na chave primária.
-
Um índice clusterizado geralmente permite consultas eficientes em colunas que são frequentemente pesquisadas por intervalos de valores (between,>, etc).
-
O clustering pode acelerar as consultas em que os dados geralmente são classificados por uma ou mais colunas específicas.
-
Um índice clusterizado pode ser reconstruído ou reorganizado sob demanda para controlar a fragmentação da tabela.
-
Esses benefícios podem ser aplicados até mesmo às visualizações.
Você pode não querer ter um índice clusterizado em:
-
Colunas que têm alterações frequentes de dados, pois o SQL Server deve reordenar fisicamente os dados no armazenamento.
-
Colunas que já estão cobertas por outros índices.
-
Chaves amplas, pois o índice clusterizado também é usado em pesquisas de índice não clusterizado.
-
Colunas GUID, que são maiores que identidades e também valores efetivamente aleatórios (provavelmente não classificados), emboranewsequentialid()pode ser usado para ajudar a mitigar o reordenamento físico durante as inserções.
-
Um motivo raro para usar um heap (tabela sem um índice clusterizado) é se os dados sempre forem acessados por meio de índices não clusterizados e o RID (identificador de linha interno do SQL Server) for menor que uma chave de índice clusterizado.
Devido a essas e outras considerações, como suas cargas de trabalho de aplicativos específicos, você deve selecionar cuidadosamente seus índices clusterizados para obter o máximo benefício para suas consultas.
Observe também que quando você cria uma chave primária em uma tabela no SQL Server, por padrão, ela cria um índice clusterizado exclusivo (se ainda não tiver). Isso significa que, se você encontrar uma tabela que não tenha um índice clusterizado, mas tenha uma chave primária (como todas as tabelas deveriam), um desenvolvedor já havia tomado a decisão de criá-la dessa maneira. Você pode querer ter uma razão convincente para mudar isso (que há muitos, como vimos). Adicionar, alterar ou descartar o índice clusterizado requer a reescrita de toda a tabela e quaisquer índices não clusterizados, portanto, isso pode levar algum tempo em uma tabela grande.
