Tenho trabalhado para melhorar o desempenho de um grande banco de dados de relatórios.
Esse banco de dados tem 2 TB de tamanho e uma das tabelas maiores heapcontém três índices não agrupados.
Cada um dos índices não agrupados lida com uma combinação de Case_IDs com dados relevantes.
No entanto, os IDs de caso não são exclusivos, pois cada entrada de caso é armazenada no mesmo heap com Case_ID.
As investigações no lado comercial das coisas me levaram ao fato de que uma combinação de Case_ID, Line_Number e Document_ID é única.
No entanto, quase todas as consultas são definidas por datas (usando uma datetimecoluna chamada DATE).
Normalmente por WHERE DATE = 'xxxx-xx-xx 00:00:00.000, ou WHERE DATE > 'xxxx-xx-xx 00:00:00.000'. E os valores Line_Number e Document_ID na maioria dos casos nem são incluídos nos relatórios.
Como tal, criei um índice clusterizado no heap (no DEV), digitado na datetimecoluna.
O desempenho dos relatórios aumentou bastante, reduzindo os tempos de consulta de 5 minutos para 3 minutos para a maioria dos meus relatórios de teste, e não vi nenhum impacto negativo nos relatórios não estipulados por data.
No entanto, estou preocupado por estar indo longe demais, pois entendo que índices clusterizados não exclusivos raramente são a solução . O que estou fazendo é uma abordagem válida? Ou devo simplesmente indexar na chave composta exclusiva e criar um índice de cobertura na datetimecoluna?
Os índices não clusterizados usam o valor da chave do índice clusterizado como um ponteiro de volta aos dados. Se você criar um índice clusterizado composto, estará tornando seus índices não clusterizados muito maiores.
Ao escolher um índice clusterizado, especialmente em tabelas com centenas de milhões de linhas, tente escolher uma única coluna estreita, se possível. ou seja, escolha um número inteiro em um campo varchar.
O campo Datetime tem 8 bytes e é relativamente estreito. Se seus dados forem inseridos por data em ordem crescente (por exemplo, conforme o tempo avança), os registros serão inseridos no final da tabela. Páginas e extensões serão adicionadas conforme necessário.
No entanto, se seus dados estiverem espalhados por todo o lugar, você terminará com divisões de página à medida que novos registros forem inseridos entre os registros existentes. Verifique se os dados da data de entrada estão corretos.
Esteja avisado de que o SQL adicionará um "uniquificador" interno de 4 bytes ao seu índice clusterizado se não for exclusivo.
Então, vá para o índice clusterizado de coluna única. As consultas que usam a coluna datetime serão muito beneficiadas e os outros índices não sofrerão.