(Não acredito que esta pergunta seja uma duplicata desta pergunta de 8 anos atrás , pois não estou perguntando sobre as vantagens de colunas superdimensionadas, estou perguntando sobre o comportamento demonstrado no artigo vinculado abaixo.)
Este artigo recente (2017) do SQLPerformance.com demonstra como a variação do comprimento máximo nde uma varchar(n)coluna afeta as estimativas de tamanho de linha do plano de consulta e as estimativas de tamanho do buffer de classificação que podem levar a avisos de desempenho e alocação de memória abaixo da média.
Nele, o autor afirma (grifo meu):
A partir daqui, vemos que, quanto maior a definição da coluna, maior a linha estimada e o tamanho dos dados . Nesta consulta simples, o custo de E/S (0,0512731) é o mesmo em todas as consultas, independentemente da definição, porque a varredura de índice clusterizado precisa ler todos os dados de qualquer maneira.
Mas há outros cenários em que essa linha estimada e o tamanho total dos dados terão impacto: operações que exigem recursos adicionais, como classificações.
Quando li essa afirmação (em negrito), fiquei surpreso porque pensei que o SQL Server obteria estimativas de tamanho de linha bastante precisas de seus STATISTICSobjetos de amostra mantidos nessas mesmas tabelas. Especialmente tendo em conta a SELECT AVG(LEN(email))consulta no artigo mostra que nenhuma coluna tem um valor superior a 77 caracteres.
O artigo também executa explicitamente um ALTER INDEX ALL ON dbo.Table REBUILD– que esta postagem do DB.SE diz que também será atualizado automaticamenteSTATISTICS .
(embora eu esteja surpreso que a palavra "estatísticas" não apareça em nenhum lugar no artigo SQLPerformance - então talvez no caso do autor as estatísticas não tenham sido atualizadas devido a alguma configuração da máquina e eles não notaram ?)
O SQL Server usa apenas o varcharlimite de comprimento de coluna para estimativas de tamanho de linha? Se não, por que o artigo SQLPerformance descreve o mesmo?
Correto. O SQL Server usa apenas o comprimento varchar (máximo especificado) ao estimar o tamanho da linha. O artigo SQLPerformance descreve com precisão a medida de tamanho de linha estimado.
A resposta mais longa
Em seu exemplo no artigo vinculado, Aaron reconstrói todos os índices para garantir que todas as versões da consulta tenham um campo de jogo igual tanto no tamanho do índice quanto nas estatísticas, de modo que os planos de execução para todos os casos sejam "ideais" e (como o experimento provou ) quase igual, mas não exatamente.
As estatísticas são usadas para estimar quantas linhas serão retornadas, não quanta memória é concedida para a execução de uma consulta.
No artigo, Aaron diz (ênfase minha):
A referência de Aaron aos "valores da etapa do histograma" é uma referência ao histograma de estatísticas . O histograma de estatísticas contém conhecimento de no máximo 201 valores de dados da tabela. Ele conhece o comprimento real desses (até 201) valores explícitos, mas não tem ideia sobre os valores entre eles.
Além disso, as estatísticas são baseadas em uma amostra de dados, portanto, pode haver linhas que não foram analisadas como parte da amostra, e confiar no comprimento mínimo/máximo/médio dos dados das estatísticas seria outra oportunidade para amostras desatualizadas ou não representativas prejudicarem afetar a execução da consulta.