Tamanho da linha, índices e varchar (max)

Question

Eu tenho uma tabela com 100m + linhas. Estamos vendo um desempenho muito ruim nas consultas conforme os dados aumentam. Notei que o tamanho da linha é muito grande (10190) e estou pensando que isso está afetando o desempenho dos índices / índice.

a tabela tem um monte de colunas configuradas com tipos de dados errados (muitos ints onde os minúsculos são mais apropriados, etc). Eu fui e atualizei a tabela para mudar o que pude.

O tamanho original da linha é 10190 e eu consegui reduzir para 10090 ajustando o ints para smallint ou tinyint.

Existem duas colunas definidas como varchar (2048). Eu mudei para varchar (max) e o tamanho da linha caiu para cerca de 6000.

Eu usei as consultas encontradas aqui link para obter o tamanho da linha.

A minha pergunta é: A alteração das colunas varchar (2048) para varchar (max) ajuda na indexação / desempenho quando essas colunas não são usadas com frequência? Que tal obter o tamanho da linha abaixo de 8000?

    

Answer 1

Não há basicamente nenhuma diferença entre VARCHAR(2048) e VARCHAR(MAX) . Um está sujeito a transbordar para a unidade de alocação de "estouro de linha", o outro está sujeito a estouro na unidade de alocação de BLOB, consulte Organização de tabelas e índices . A configuração padrão da opção large value types out of row table é 0, a menos que tenha sido alterada, o VARCHAR(MAX) permanecerá na linha, se possível, assim como VARCHAR(2048) .

Eu recomendaria executar sys.dm_db_index_physical_stats e obter as linhas max, min e avg reais tamanho, bem como avg_page_space_used_in_percent . Isso fornecerá uma imagem mais precisa do (s) tamanho (s) verdadeiro (s) da linha, em vez do tamanho teórico declarado.

    

Answer 2

A primeira coisa que eu verificaria seria o índice clusterizado. Deve ser definido como algo estreito, uma coluna ou com o menor número de colunas possível usando um índice composto. Idealmente, deve ser definido como algo que possa ser seqüencial, como bigint, not uniqueIdentifier. Se estiver usando um índice clusterizado uniqueIdentifier, algumas pessoas verão melhorias de desempenho adicionando um índice clusterizado bigint e mantendo o uniqueIdentifier como um índice exclusivo.

O SSMS às vezes tem informações úteis onde os índices podem estar faltando: link

A próxima coisa seria analisar as consultas. Descubra quais consultas estão consumindo mais tempo e determine se estão atingindo índices de cobertura ou executando varreduras de tabela. Você pode querer publicar algumas das consultas sql e detalhes dos índices existentes.

    

Answer 3

As consultas são escritas para solicitar apenas os dados de que precisam, ou seja, não há SELECT *?

Eu verificaria a configuração geral do servidor SQL, verifique se a configuração segue as práticas recomendadas (veja o excelente checklist ); então talvez execute algum perfmon para ver onde estão seus gargalos, verifique primeiro o comprimento da fila de disco.