Eu tenho uma tabela com uma coluna id que é incrementada automaticamente e várias outras colunas informativas. As linhas são inseridas nesta tabela com muita frequência. Quando os dados são lidos, a maioria das consultas é filtrada por uma chave estrangeira e um intervalo de datas.
Atualmente, há um índice clusterizado na coluna id e um índice não clusterizado nas duas colunas de importância (TrackerId e DateRecorded). Se eu trocar os índices, nossas consultas serão muito mais rápidas. Isso afetaria negativamente os tempos de inserção?
Em seu design real, você tem uma chave de índice clusterizada exclusiva, estática, estreita e cada vez maior que não causa divisões de página quando as linhas são inseridas.
Se você criar seu índice clusterizado em
TrackerIdeDateRecorded(você deseja usar essas colunas nesta ordem, certo? porque seu predicado de busca tem uma igualdade emTrackerIde um intervalo emDateRecorded), você obterá uma chave clusterizada não crescente que causará divisões de página emINSERT.Será mais amplo e talvez não único.
Mas a decisão final depende de você. Não sabemos se esta tabela tem mais leituras ou gravações, e as divisões de página podem ser atenuadas escolhendo a
Fill Factorrecompilação de índice apropriada e regular.Aqui você pode ler mais sobre isso: Mitigação da fragmentação do índice por Paul Randal