Pesquisando na web, encontrei conselhos conflitantes sobre se há um impacto no desempenho ao especificar VARCHARcolunas excessivamente largas, por exemplo VARCHAR(255), quando VARCHAR(30)provavelmente será o suficiente.
Eu vejo consistentemente que há um impacto no desempenho se a linha inteira exceder 8060 bytes. Fora isso, vejo discordância.
A afirmação é verdadeira de que o padrão é SET ANSI PADDING ON= potencial para muitos espaços à direita ? Contanto que a largura total da linha seja menor que 8060, há alguma preocupação real de desempenho em VARCHARcolunas superdimensionadas?
Evidência de que a largura da coluna é importante
O mesmo vale para os tipos de dados CHAR e VARCHAR. Não especifique mais caracteres nas colunas de caracteres que você precisa.
https://www.sql-server-performance.com/w2k-filesystem-affects-performance/
- Comprimento é uma restrição nos dados (como CHECK, FK, NULL etc)
- Desempenho quando a linha excede 8060 bytes
- Não pode ter restrição ou índice exclusivo (a largura da coluna chave deve ser < 900)
- O padrão é
SET ANSI PADDING ON= potencial para muitos espaços à direita
Quais são as consequências da configuração de varchar(8000)?
Evidência de que a largura da coluna NÃO importa
Se você está falando sobre varchar e nvarchar, não, não há penalidade por permitir um comprimento de campo maior.
https://stackoverflow.com/questions/7025996/overstating-field-size-in-database-design
O tipo de dados varchar, por outro lado, consome apenas a quantidade de espaço real usado mais 2 bytes para sobrecarga
http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf
A pergunta pode ser melhor formulada como:
Em geral, há pouca vantagem e várias desvantagens, conforme apontam as várias respostas vinculadas. Além de qualquer outra preocupação, considere que o SQL Server não é de código aberto: existem muitos 'números mágicos' e heurísticas aplicadas com base nas informações fornecidas ao sistema. Sem acesso ao código-fonte, nunca poderíamos ter certeza de qual seria o impacto dessa prática.
Em alguns casos , em que o comprimento médio de uma coluna é significativamente maior do que os 50% assumidos pelo SQL Server ao calcular as concessões de memória de classificação/hash, você pode ver uma melhoria de desempenho especificando demais o comprimento máximo. Esta é uma solução duvidosa e provavelmente só deve ser aplicada por um
CASTouCONVERT(com comentários!) explícito, em vez de alterar a definição da coluna base. Às vezes, será preferível reescrever a consulta para classificar chaves em vez de linhas inteiras.Onde o tamanho máximo da linha pode exceder o limite de linha (mesmo que nenhuma linha o faça), a exclusão de linhas pode causar divisão de página inesperada se um acionador estiver presente. As atualizações também podem levar à fragmentação por meio do mesmo mecanismo.
O SQL Server faz um bom trabalho na maioria dos casos em que é fornecido com informações boas e precisas de metadados. Comprometer este princípio de 'conveniência' parece imprudente para mim. Uma abordagem sensata é escolher um valor de comprimento máximo que seja razoável de acordo com os dados reais a serem armazenados e quaisquer alterações previsíveis.
COMO você indicou, contanto que o tamanho da linha não exceda 8060 (ou qualquer que seja o máximo definido), não há diferença de desempenho em usar VARCHAR(30) ou VARCHAR(255) ou maior. A comparação CHAR para VARCHAR do artigo vinculado não é realmente pertinente. Embora eu concorde que você não deve especificar mais espaço do que tem certeza de que precisa, em muitos casos você não sabe quanto espaço realmente precisará. Portanto, seja liberal com o espaço VARCHAR - tenho certeza de que aumentar o tamanho dos campos requer uma reconstrução da tabela, enquanto diminuir é uma simples instrução ALTER TABLE.