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

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.

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.

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

Kimberly Tripp tem uma fantástica publicação no blog sobre esse tópico. Eu poderia parafrasear, mas confie em mim, não faria justiça. Tenha uma leitura. http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

Enquanto estiver lá, confira algumas de suas outras postagens sobre o tópico de chaves de cluster. Existe uma boa variedade de conhecimentos no site dela.

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 ...