É meu entendimento que no SQL Server, você pode ter uma Chave Primária que não é clusterizada e ter outro índice que é o clusterizado.
Para mim, isso parece o mesmo que ter apenas uma chave primária e uma chave ÚNICA extra.
Então eu tenho duas perguntas:
se uma chave primária não estiver em cluster, ela armazena todas as colunas com ela? Ou apenas as colunas de chave primária e as colunas que fazem referência ao índice clusterizado?
Acabei de ler que, se o PK não for o índice clusterizado, o índice clusterizado NÃO precisa ser ÚNICO (mas é altamente recomendável). Isso significa que a tabela pode ser "classificada aleatoriamente" nas linhas com a mesma chave?
Não, isso é uma característica do índice clusterizado, não da chave primária. Uma chave primária não clusterizada armazenará apenas os campos em que está definida, além dos campos-chave do índice clusterizado.
As linhas da tabela sempre serão classificadas logicamente pelos campos de índice clusterizados. No caso em que o índice clusterizado não é único e existem duas linhas com os mesmos valores para a chave do índice clusterizado, essas linhas recebem um identificador de linha exclusivo que é armazenado nos bastidores (esse unificador de 4 bytes só é adicionado ao linhas de chave duplicadas). Este é o fator determinante em como eles são classificados em relação uns aos outros.
Uma razão pela qual alguém pode optar por tornar a chave primária um índice não clusterizado é porque eles encontram benefícios de desempenho em ter os dados classificados logicamente de maneira diferente dos campos que identificam a exclusividade da linha (independentemente de o índice clusterizado ser exclusivo ou não).
Um exemplo seria se um GUID fosse usado em uma
UNIQUEIDENTIFIERcoluna como a chave primária de sua tabela. Os GUIDs são ótimos para exclusividade (na maioria das vezes), mas geralmente não são uma ótima maneira de manter seus dados classificados por causa de seus valores aleatórios . Em vez disso, você pode ter um conjunto natural de campos nessa tabela, nos quais suas consultas normalmente se unem ou filtram, que não são necessariamente exclusivos, o que, em vez disso, cria um bom índice clusterizado. Ou mesmo um conjunto de campos que você normalmente ordena em suas consultas pode ser um candidato a um índice clusterizado, para eliminar uma operação de classificação pesada do plano de consulta. Os dados serão então classificados em uma ordem que faça sentido em vez de pelos valores semi-aleatórios de um GUID.Consulte os internos de índices clusterizados do SQL Server com exemplos para obter mais informações sobre como funcionam os índices clusterizados.
O tipo de índice, clusterizado ou não clusterizado, determina implicitamente as colunas não-chave armazenadas nos nós folha de índice de árvore b. Isso é verdade independentemente de o índice ser exclusivo ou não, ou oferecer suporte a uma chave primária ou restrição exclusiva.
Um índice clusterizado organiza a própria tabela como um índice b-tree (em contraste com um heap quando não existe nenhum índice clusterizado). Todas as colunas são armazenadas nos nós folha de um índice clusterizado porque essas são as páginas/linhas de dados reais. O localizador de linha exclusivo é a chave de índice clusterizado mais um exclusivo interno para valores de chave não exclusivos, quando aplicável.
Um índice não clusterizado armazena as colunas de chave de índice não clusterizado, localizador de linha (chave de índice clusterizado), além de colunas incluídas (se especificadas) nos nós folha de índice.
Uma tabela é ordenada logicamente pela chave do índice clusterizado (exclusivo ou não). As linhas com a mesma chave de índice clusterizado serão adjacentes, não aleatórias.