Se eu tiver um campo de entrada de dados em uma tabela do SQL Server, posso indexá-lo com eficiência?

Question

Eu tenho um banco de dados back-end do SQL Server. No meu entender, os índices agrupados são mais eficientes, mas eles pedem fisicamente as páginas para torná-lo eficiente. Então, se é um campo inserido pelo usuário, toda vez que um novo registro é adicionado, toda a tabela precisa se reestruturar.

Isso não pode ser eficiente. Então, colocar um índice regular em um campo eficiente nessa instância? ou você deixaria isso sem ser indexado?

    

Answer 1

Como regra geral, você deve usar apenas índices agrupados para campos de identidade, e os números automáticos são os melhores, já que eles estão sempre aumentando. A atualização de uma coluna de identidade é algo que você deve fazer uma vez a cada milênio, e certianly não no tempo de execução do aplicativo, portanto, nunca precisará reordenar o conteúdo da página por meio de uma instrução DML padrão.

Dentro dessas restrições, índices agrupados são muito eficientes, mas, como você apontou, se usados incorretamente, eles podem ser um grande obstáculo para o desempenho de instruções DML no campo indexado.

Portanto, resposta curta, não use índices clusterizados para campos inseridos pelo usuário.

Quanto aos índices não agrupados, eles podem ser uma grande vantagem ou uma limitação, dependendo de seu uso. Os NCIs são muito bons para recuperar um ou um pequeno número de linhas, mas o tamanho do índice cresce com cada campo adicionado a ele, índices complicados de muitos campos, ou índices que só poderiam resolver uma consulta para um grande número de linhas em pelo menos não fornecem os ganhos, e são frequentemente mais difíceis do que valem.