Por que a propriedade Clustered Index está habilitada em algumas colunas e não em outras?

Chave primária e índice clusterizado são duas coisas diferentes, embora sejam frequentemente usados ​​em conjunto. Algumas possíveis razões pelas quais sua tabela acabou assim:

(a) poderia ter sido criado com uma chave primária não clusterizadaPRIMARY KEY NONCLUSTERED usando , então o índice clusterizado foi adicionado.

(b) o índice clusterizado poderia ter sido adicionado e, em seguida, a chave primária adicionada (nesse caso, não pode ser agrupado, pois já existe um índice clusterizado).

Qualquer um desses poderia ter sido decisões intencionais de design, acidentes, mudanças em pensamentos posteriores, etc.

Ignore a propriedade na exibição de design do Management Studio. O índice clusterizado é a tabela, mas é definido pela(s) coluna(s) especificada(s). As outras colunas ainda fazem parte tecnicamente do índice clusterizado, mas não são colunas-chave no índice. Chamar isso de "ativado/desativado" é enganoso.

Só pode haver um índice clusterizado, porque o índice clusterizado são os próprios dados da tabela. É uma forma de organizar os dados da tabela com base em uma chave de agrupamento. É semelhante às tabelas organizadas por índice (IOT) da Oracle. Índices não clusterizados são estruturas de dados separadas. Os índices agrupados são os próprios dados organizados como uma b-tree.

Por padrão, o SQL Server torna a chave primária como um índice clusterizado, se ainda não houver um. Parece que, no seu caso, a chave primária foi criada como um 'índice não agrupado' e a coluna District como um 'índice agrupado'.

Você pode ter apenas um índice clusterizado por tabela. Uma chave primária não é um índice clusterizado. Para responder às suas perguntas:

Se pode haver apenas um índice clusterizado, por que District tem essa propriedade habilitada quando SerialNum já está definido como chave primária? Isso ocorre porque o índice clusterizado é criado em District. Somente isso aparecerá como ativado e o restante como desativado.

Se pode haver mais índices clusterizados, como habilitar essa propriedade para a coluna SchemeType? Você não pode ter mais de um índice clusterizado em uma tabela. Você terá que descartar o índice clusterizado em District e recriar um para SchemeType. Se você ainda deseja manter o índice clusterizado em District, um truque que pode usar é criar uma exibição indexada e, em seguida, criar um índice clusterizado na exibição de SchemeType. Você pode precisar da edição Enterprise para isso.

• No MySQL, que vejo em outras postagens que você usa, a chave primária e o índice clusterizado são sempre os mesmos.
• No SQL Server, eles podem ser diferentes.
• No SQL Server, só pode haver um índice clusterizado. O índice clusterizado garantirá que a tabela seja ordenada fisicamente de acordo com esse índice.
• É claro que você pode ter muitos índices não clusterizados além de seu único índice clusterizado e, normalmente, você terá um clusterizado e um ou alguns índices não clusterizados em algumas de suas tabelas.
• Normalmente, no SQL Server, as chaves primárias têm o índice clusterizado (e acho que é o padrão), mas é possível configurar outra coluna (ou colunas) com o índice clusterizado.
• É até possível ter duas ou mais colunas nesse índice clusterizado. Você não diz se a coluna SerialNum também está agrupada ou não, mas se você perceber que ambas estão agrupadas, terá um único índice que abrange duas colunas e haverá uma propriedade de inteiro de ordem de agrupamento que será a ordem em que esses as colunas determinam o layout da tabela física (por exemplo, "ordenado por Distrito primeiro e dentro do distrito, ordenado por SerialNum"). Observe que adicionar mais colunas a esse índice clusterizado tenderá a reduzir o desempenho em vez de melhorá-lo, a menos que a ordem física corresponda exatamente aos principais casos de consulta nessa tabela o suficiente para superar a penalidade de desempenho INSERT reduzida que acompanha a garantia dessa ordem física.
• Em seu sistema, se o distrito estiver agrupado (mas SerialNum não), isso pode ser um bom design se as consultas nessa tabela se juntarem com mais frequência a "Distrito" ou filtrarem "Distrito" do que "Número de série". (Eu vi esse tipo de coisa em cenários onde algo como SerialNum é uma chave substituta auto-incrementada que não é muito usada em outros lugares em seu modelo de dados e se usuários finais/aplicativos/relatórios tiverem joins/where/groupby/ cláusulas orderby com District, mas raramente ou nunca contra SerialNum.)