Largura da coluna VARCHAR do SQL Server

Pesquisando na web, encontrei conselhos conflitantes sobre se há um impacto no desempenho ao especificar colunas VARCHAR excessivamente amplas, por exemplo, VARCHAR (255) quando VARCHAR (30) provavelmente ocorrerá.

Consigo consistentemente concordar que há um impacto no desempenho se a linha inteira exceder 8060 bytes. Fora isso, eu vejo desacordo.

A afirmação é verdadeira The default is SET ANSI PADDING ON = potential for lots of trailing spaces? Contanto que a largura total da linha seja menor que 8060, existem problemas reais de desempenho nas colunas VARCHAR com tamanho excessivo?

Evidência de que a largura da coluna é importante

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must be < 900)
• The default is SET ANSI PADDING ON = potential for lots of trailing spaces

Quais são as conseqüências da configuração do varchar (8000)?

Evidência de que a largura da coluna NÃO importa

If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design

The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

A pergunta pode ser melhor declarada como:

"Qual é a vantagem de especificar em excesso o comprimento máximo de uma coluna de comprimento variável?"

Em geral, há pouca vantagem e várias desvantagens, como apontam as várias respostas vinculadas. Além de quaisquer outras preocupações, 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 , onde o comprimento médio de uma coluna é significativamente superior aos 50% assumidos pelo SQL Server ao calcular concessões de memória de classificação / hash, você pode observar uma melhora no desempenho, especificando em excesso o comprimento máximo. Esta é uma solução duvidosa e provavelmente só deve ser aplicada por um explícito CASTou CONVERT(com comentários!) Em vez de alterar a definição da coluna base. Às vezes, é preferível reescrever a consulta para classificar as chaves em vez de linhas inteiras de qualquer maneira.

Onde o tamanho máximo da linha pode exceder o limite de linha (mesmo que nenhuma linha realmente o faça), a exclusão de linhas pode causar divisão inesperada de página se houver um acionador. As atualizações também podem levar à fragmentação pelo mesmo mecanismo.

O SQL Server faz um bom trabalho na maioria dos casos em que é fornecido com informações precisas e boas dos metadados. Comprometer esse princípio de "conveniência" me parece imprudente. Uma abordagem sensata é escolher um valor de comprimento máximo razoável de acordo com os dados reais a serem armazenados e quaisquer alterações previsíveis.

Como você indicou, desde que o tamanho da linha não exceda 8060 (ou qualquer que seja o máximo definido), não há diferença de desempenho no uso de 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 você 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 instrução ALTER TABLE simples.