SQL 2005: chaves, índices e restrições Perguntas

https://stackoverflow.com/questions/1403927

05-07-2019
|

Pergunta

Eu tenho uma série de perguntas sobre Keys, índices e restrições em SQL, SQL 2005 em particular. Tenho vindo a trabalhar com SQL por cerca de 4 anos, mas eu nunca fui capaz de obter respostas definitivas sobre este tema e há sempre informações contraditórias sobre posts, etc. A maioria das tabelas de tempo eu criar e usar só tem uma coluna de identidade que é uma chave primária e outras tabelas apontar para ele através de uma chave estrangeira.

Com unir tabelas não tenho identidade e criar uma chave primária composta sobre as colunas da chave estrangeira. O seguinte é um conjunto de declarações de minhas crenças atuais, o que pode estar errado, por favor me corrijam se assim for, e outras questões.

Então aqui vai:

Como eu entendo a diferença entre um cluster e índice não cluster (independentemente de ele é único ou não) é que o índice agrupado afeta a ordem física dos dados em uma tabela (portanto, você pode ter apenas um em uma tabela ), ao passo que um índice não agrupado constrói uma estrutura de dados árvore. Ao criar índices por que eu deveria me importar com cluster vs não agrupadas? Quando devo usar um ou o outro? Foi-me dito que a inserção e exclusão são lentos com índices não agrupados como as necessidades de árvore para ser "reconstruído". Eu levá-la índices agrupados não afetam o desempenho dessa maneira?

Eu vejo que as chaves primárias são realmente Índices apenas cluster que são únicos (que eles têm de ser agrupados?). O que é especial sobre uma chave primária vs um índice exclusivo de cluster?

Também já vi restrições, mas eu nunca usei-los ou realmente olhou para eles. Foi-me dito que o objetivo das restrições é que eles são para reforçar a integridade dos dados, enquanto índices são destinadas a performance. Eu li também que as restrições são acually implementado como Índices de qualquer maneira para que eles sejam "o mesmo". Este direito não soa para mim. Como são restrições diferentes para índices?

Solução

índices agrupados são, como você colocá-lo corretamente, o definição de como os dados de uma tabela é armazenado fisicamente, ou seja, você tem uma árvore-B classificados usando a chave de cluster e você tem os dados no nível folha.

índices não agrupados em por outro lado são estruturas de árvores separadas que no nível folha só tem a chave de cluster (ou um RID se a tabela é uma pilha), o que significa que quando você usa um índice não agrupado, você vai ter que usar o índice agrupado para obter as outras colunas (a menos que o seu pedido é totalmente coberto pelo índice não-agrupado, o que pode acontecer se você solicitar apenas as colunas que constituem as colunas de chave índice não agrupado).

Quando você deve usar um ou o outro? Bem, desde que você pode ter apenas um índice agrupado, defini-lo nas colunas que faz mais sentido, ou seja, quando você olha para cima clientes por ID maior parte do tempo, definir um índice agrupado na ID. índices não agrupados devem ser definidos em colunas que são usadas com menos frequência.

Com relação ao desempenho, inserções ou atualizações que mudam a chave de índice são sempre dolorosos, independentemente de saber se é um clusted no índice não-cluster, desde divisões de página pode acontecer, que os dados forças para ser movido entre as páginas (mover as páginas de um índice agrupado dói mais, uma vez que você tem mais dados no nível de folha). Assim, a regra geral é para evitar a alteração da chave de índice e inserção de novos valores para que eles pudessem ser sequencial. Caso contrário, você vai encontrar a fragmentação e terá de recriar o índice em uma base regular.

Finalmente, em relação restrições, por definição, eles não têm nada a ver com índices, contudo servidor SQL escolheu para implementá-las usando índices. Por exemplo. atualmente, uma restrição exclusiva é implementado como um índice, no entanto, isso pode mudar em uma versão futura (embora eu duvido que vai acontecer). O tipo de índice (agrupado ou não) é até você, basta lembrar que você só pode ter um índice agrupado.

Se você tem mais perguntas desse tipo, eu recomendo a leitura este livro , que inclui os seguintes tópicos em profundidade.

Outras dicas

A sua suposição sobre o cluster vs não-agrupado é muito bom

Parece também que a chave primária impõe uniquenes não nulos, enquanto o índice exclusivo não impõe não nula principal vs única

O chave primária é um conceito lógico em teoria banco de dados relacional - é uma chave (e geralmente também um índice) que é projetado para identificar exclusivamente qualquer uma das suas linhas. Por isso, deve ser único e não pode ser NULL.

A chave cluster é um conceito de armazenamento físico do SQL Server especificamente. É um índice especial que não é usado apenas para pesquisas etc., mas também define a estrutura física de seus dados em sua tabela. Em uma lista telefônica impressa na cultura da Europa Ocidental (exceto, talvez, para a Islândia), o índice agrupado seria "sobrenome, nome".

Uma vez que o índice de agrupamento define o layout físico de dados, você pode sempre apenas ter um desses (ou nenhum - não é recomendado, embora).

Requisitos para uma chave de cluster são:

deve ser exclusivo (se não, SQL Server irá adicionar um "uniqueifier" 4-byte)
deve ser estável (nunca mudando)
deve ser o menor possível (INT é melhor)
deve ser cada vez maior (pense: IDENTIDADE)

SQL Server faz a sua chave primária a chave de cluster por padrão - mas você pode mudar isso se você precisa. Além disso, lembre-se: as colunas que compõem a chave de cluster será adicionado a cada entrada de cada índice não agrupado na sua mesa - assim que você quer manter sua chave de cluster tão pequeno quanto possível. Isso ocorre porque a chave de cluster será usado para fazer o "marcador de pesquisa" - se você encontrar uma entrada em um índice não-cluster (por exemplo, uma pessoa pelo seu número de segurança social) e agora você precisa pegar toda a linha de dados para obter mais detalhes, você precisa fazer uma pesquisa, e para isso, a chave de cluster é usado.

Há um grande debate sobre o que faz um bom ou agrupamento útil / chave e ou primária - é aqui algumas excelentes posts para ler sobre isso:

Marc

Você tem várias perguntas. Eu vou quebrar alguns deles:

Ao criar índices por que eu deveria me importar com cluster vs não agrupadas?

Às vezes, você se importa como as linhas são organizados. Depende de seus dados e como você vai usá-lo. Por exemplo, se sua chave primária é um uniqueidentifier, você pode não querer que ele seja CLUSTERED, porque os valores GUID são essencialmente aleatório. Isso fará com que SQL para inserir linhas aleatoriamente ao longo da mesa, causando página splits qual o desempenho ferido. Se o seu valor de chave primária será sempre incremento sequencialmente (int IDENTITY por exemplo), então você provavelmente quer que seja CLUSTERED, então sua mesa será sempre crescer no final.

Uma chave primária é CLUSTERED por padrão, e na maioria das vezes você não precisa se preocupar com isso.

Foi-me dito que a inserção e exclusão são lentos com índices não agrupados como as necessidades de árvore para ser "reconstruído". Eu levá-la índices agrupados não afetam o desempenho dessa maneira?

Na verdade, o oposto pode ser verdade. índices NONCLUSTERED são mantidos como uma estrutura de dados separado, mas a estrutura está concebida para permitir que algumas modificações, sem necessidade de ser "re-construídas". Quando o índice é criado inicialmente, você pode especificar o FILLFACTOR, que especifica a quantidade de espaço livre para deixar em cada página do índice. Isso permite que o índice de tolerar algumas modificações antes de uma divisão da página é necessário. Mesmo quando uma divisão da página deve ocorrer, ela afeta apenas as páginas vizinhas, não todo o índice.

O mesmo comportamento se aplica a índices CLUSTERED, mas desde índices CLUSTERED armazenar os dados atuais da tabela, as operações a divisão da página no índice pode ser muito mais caro, porque toda a linha pode precisam ser movidos (versus apenas as colunas de chave e o ROWID em um índice NONCLUSTERED).

A seguir MSDN página fala sobre FILLFACTOR e página splits: http://msdn.microsoft.com/en-us /library/aa933139(SQL.80).aspx

O que é especial sobre uma chave primária vs um índice exclusivo de cluster? Como são restrições diferentes para índices?

Para esses dois eu acho que é mais sobre declarando suas intenções. Quando você chamar algo um PRIMARY KEY você está declarando que ele é o principal método para a identificação de uma determinada linha. É um PRIMARY KEY fisicamente diferente de um CLUSTERED UNIQUE INDEX? Não tenho certeza. O comportamento é essencialmente o mesmo, mas as suas intenções podem não ser claro para alguém que trabalha com seu banco de dados.

No que diz respeito restrições, existem muitos tipos de restrições. Para uma UNIQUE CONSTRAINT, não há realmente uma diferença entre isso e um UNIQUE INDEX, além de declarar a sua intenção. Existem outros tipos de restrições que não mapeiam diretamente a um tipo de índice, tais como restrições CHECK, restrições DEFAULT e restrições FOREIGN KEY.

Eu não tenho tempo para responder a isso em profundidade, por isso aqui estão algumas informações fora do topo da minha cabeça:

Você está certo sobre índices de cluster. Eles reorganizar os dados físicos de acordo com a ordem de classificação do índice agrupado. É possível utilizar índices agrupados especificamente para consultas gama-ligados (por exemplo, entre as datas).

PKs são por padrão em cluster, mas não tem que ser. Isso é apenas uma configuração padrão. O PK é suposto ser um UID para a linha.

As restrições podem ser implementados como índices (por exemplo, restrições originais), mas também pode ser implementado como valores padrão.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow