'Evitar criar um índice clusterizado com base em uma chave de incremento' é um mito dos dias do SQL Server 2000?

22

Nossos bancos de dados consistem em muitas tabelas, a maioria delas usando uma chave substituta inteira como chave primária. Cerca de metade dessas chaves primárias estão em colunas de identidade.

O desenvolvimento do banco de dados começou nos dias do SQL Server 6.0.

Uma das regras seguidas desde o início foi: Evite criar um índice em cluster com base em uma chave de incremento , conforme você encontra nestas Dicas de otimização de índice .

Agora, usando o SQL Server 2005 e o SQL Server 2008, tenho a forte impressão de que as circunstâncias mudaram. Enquanto isso, essas colunas de chave primária são os primeiros candidatos perfeitos para o índice clusterizado da tabela.

sql-server sql-server-2005 clustered-index bernd_k
fonte

Respostas:

34

O mito remonta ao SQL Server 6.5, que adicionou o bloqueio no nível da linha . E sugerido aqui por Kalen Delaney .

Tratava-se de "pontos de acesso" do uso da página de dados e o fato de uma página 2k inteira (SQL Server 7 e superior usar 8k páginas) estar bloqueada, em vez de uma linha inserida Edit, fev 2012

Artigo oficial encontrado por Kimberly L. Tripp

"O debate sobre o índice clusterizado continua ..."

Pontos de acesso eram algo que tentamos evitar muito antes do SQL Server 7.0 devido ao bloqueio no nível da página (e foi aí que o termo hot spot se tornou negativo). De fato, não precisa ser um termo negativo. No entanto, como o mecanismo de armazenamento foi novamente pesquisado / reprojetado (no SQL Server 7.0) e agora inclui o verdadeiro bloqueio no nível de linha, essa motivação (para evitar pontos de acesso) não existe mais.

Editar, maio de 2013

O link na resposta de lucky7_2000 parece dizer que pontos de acesso podem existir e causam problemas. No entanto, o artigo usa um índice em cluster não exclusivo no TranTime. Isso requer que um uniquificador seja adicionado. O que significa que o índice não aumenta estritamente monotonicamente (e é muito amplo). O link nessa resposta não contradiz esta resposta ou meus links

Em nível pessoal, trabalhei em bancos de dados nos quais inseri dezenas de milhares de linhas por segundo em uma tabela que possui uma coluna grande de IDENTITY como PK em cluster.

gbn
fonte
23

Para resumir, nas versões modernas do SQL Server, uma chave em cluster em uma coluna de identidade é a opção preferida atualmente.

mrdenny
fonte
Curto, simples, direto ao ponto, então esse é o meu +1. Certifique-se de verificar o link para SQLSkills, pois há muitas informações boas lá.
18711 AndrewsQL #
12
Isso soa como um comando. Nenhuma explicação ou lógica para isso devemos ...
gbn
Não apenas soa como um comando, mas também está errado. Qualquer banco de dados com uma quantidade muito alta de inserções / s terá problemas com o ponto de acesso se você usar chaves seqüenciais.
Thomas Kejser
1
Eu disse preferido, não obrigatório. Para aplicativos normais que compõem 98% dos bancos de dados no mundo, uma chave agrupada em uma coluna de identidade funciona perfeitamente.
Mrdenny
4

verifique este post:

http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonically-increasing-clustered-index-keys-can-cause-latch-contention.aspx

criar um índice clusterizado com base em uma chave de incremento pode criar pontos de acesso tão ruins para o desempenho ...

lucky7_2000
fonte
1
+1 por fornecer esse link. Existem algumas dicas interessantes lá. Mas acho que o resultado seria muito mais convincente, se ele comparasse o cenário fornecido com um com o índice não clusterizado cidx_trantime em tblTransactions (TranTime) ou alguma outra alternativa. Lembre-se de que, quando você gera tantos dados, deve haver maneiras eficientes de recuperá-los; você não pode simplesmente jogar tudo em uma pilha.
bernd_k
@bernd_k: este é um link de exemplo ruim. A tabela a criança tem uma chave em cluster não exclusivo ruim que requer uma uniquifier interna
GBN
1
Tente este experimento então: kejser.org/boosting-insert-speed-by-generating-scalable-keys
Thomas Kejser