O que há de errado no código. ou seus resultados, ilustrando que o índice agrupado é mau [1]?
e como desmascarar, ou seja, retornar aos mitos habituais e às melhores práticas?
[1]
Desmistificando mitos sobre índices clusterizados - parte 3 (script de exemplo)
http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/16/377.aspx
Editado por gbn, janeiro de 2012
O link morto costumava ter um script que "provava" que os índices agrupados eram ruins.
Pergunta SO semelhante: https://stackoverflow.com/questions/4034076/reasons-not-to-have-a-clustered-index-in-sql-server-2005
Esse script tem um índice clusterizado varchar bastante amplo. E também precisa de uma reconstrução de índice depois de preenchê-lo com dados aleatórios: você terá uma fragmentação massiva.
Um bom índice clusterizado é estreito, numérico e monotonicamente crescente: é por isso que as pessoas usam chaves substitutas...
Uma tabela sem um índice clusterizado é chamada de "heap" porque é exatamente isso: uma pilha de dados no disco. E continuará assim, não importa o quanto você reconstrua seus índices NC. Fora de algo como tabelas de preparação (com um padrão de uso de carregamento/truncado), não há motivo para não ter uma chave primária em cluster.
Editar: o link não desmascara um mito de índice clusterizado, mas mostra como criar um índice clusterizado inadequado e por que a manutenção do índice é importante. As partes 1 e 2 mencionam pesquisas de favoritos (agora pesquisas de chave no SQL Server 2005+): um bom índice NC cobrirá para que elas não aconteçam.
Para aprender sobre índices, sugiro os diversos artigos do Simple Talk. como este
Índices agrupados não são ruins. No entanto, nem todas as tabelas se beneficiarão de um índice clusterizado e, muitas vezes, são mal utilizadas de forma descuidada e prejudicial. Portanto, o objetivo dos artigos de Gregg (e de outros) é demonstrar algumas das armadilhas.