Tenho uma exposição limitada ao BD e só usei o BD como programador de aplicações. Eu quero saber sobre Clustered
e Non clustered indexes
.
Eu pesquisei no Google e o que eu encontrei foi :
Um índice agrupado é um tipo especial de índice que reordena o modo os registros na tabela são fisicamente armazenado. Portanto, a tabela só pode ter um índice agrupado. Os nós da folha de um índice agrupado contém os dados páginas. Um índice não incluído é um tipo especial de índice em que o a ordem lógica do índice não corresponder à ordem física de armazenamento de as filas no disco. O nó de folha de um o índice não incluído não consiste em as páginas de dados. Em vez disso, a folha os nós contêm linhas de índice.
O que eu encontrei em SO foi https://stackoverflow.com/questions/91688/what-are-the-differencespros-cons-between-clustered-and-non-clustered-indexes.
Alguém pode explicar isto em inglês simples?
Com um índice agrupado, as linhas são armazenadas fisicamente no disco na mesma ordem que o índice. Portanto, só pode haver um índice agrupado.
Com um índice não agrupado há uma segunda lista que tem indicações para as filas físicas. Você pode ter muitos índices não agrupados, embora cada novo índice irá aumentar o tempo que leva para escrever novos registros.
É geralmente mais rápido ler a partir de um índice agrupado se você quiser recuperar todas as colunas. Você não tem que ir primeiro ao índice e depois à tabela.
Escrever para uma tabela com um índice agrupado pode ser mais lento, se houver necessidade de reordenar os dados.
Um índice agrupado significa que você está dizendo ao banco de dados para armazenar valores próximos uns aos outros no disco. Isto tem o benefício de um rápido scan/recuperação de registros que caem em algum intervalo de valores de índice agrupados.
Por exemplo, você tem duas tabelas, Cliente e Ordem:
Customer
----------
ID
Name
Address
Order
----------
ID
CustomerID
Price
Se desejar recuperar rapidamente todas as encomendas de um determinado cliente, pode desejar criar um índice agrupado na coluna "CustomerID" da tabela de encomendas. Desta forma, os registros com o mesmo CustomerID serão fisicamente armazenados próximos uns dos outros em disco (em cluster), o que acelera a sua recuperação.
P.S. O índice no CustomerID obviamente não será único, então você precisa ou adicionar um segundo campo para "singularizar" o índice ou deixar a base de dados tratar disso para você, mas isso é outra história.
Em relação a múltiplos índices. Você pode ter apenas um índice agrupado por tabela porque isso define como os dados são fisicamente organizados. Se você deseja uma analogia, imagine uma grande sala com muitas tabelas dentro dela. Você pode colocar essas tabelas para formar várias filas ou puxá-las todas juntas para formar uma grande tabela de conferência, mas não as duas ao mesmo tempo. Uma tabela pode ter outros índices, eles então apontarão para as entradas no índice agrupado que, por sua vez, finalmente dirá onde encontrar os dados reais.
Uma regra muito simples e não técnica seria que os índices agrupados são normalmente utilizados para a sua chave primária (ou, pelo menos, uma coluna única) e que os não agrupados são utilizados para outras situações (talvez uma chave estrangeira). De facto, o SQL Server irá, por defeito, criar um índice agrupado na(s) sua(s) coluna(s) de chave primária(s). Como terá aprendido, o índice agrupado relaciona-se com a forma como os dados são fisicamente ordenados no disco, o que significa que é uma boa escolha geral para a maioria das situações.