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

22

Como o varchar ocupa um espaço em disco proporcional ao tamanho do campo, existe alguma razão pela qual nem sempre devemos definir varchar como o máximo, por exemplo, varchar(8000)no SQL Server?

Na tabela create, se eu vir alguém fazendo varchar(100), devo dizer que não, você está errado, deve fazer varchar(8000)?

sql-server varchar Aleksandr Levchuk
fonte
Acho que precisamos diferenciar aqui entre o uso na tabela create e o uso nas declarações de parâmetros dos procedimentos armazenados. Para a segunda interpretação, veja minha pergunta dba.stackexchange.com/questions/1772/…
bernd_k

Respostas:

18
  • O comprimento é uma restrição nos dados (como CHECK, FK, NULL, etc.)
  • Desempenho quando a linha exceder 8060 bytes
  • Não pode ter restrição ou índice exclusivo (a largura da coluna da chave deve ser <900)
  • O padrão é SET ANSI PADDING ON = potencial para muitos espaços à direita serem armazenados
  • O SQL Server assumirá que o comprimento médio é de 4000 para operações de classificação, alocando memória com base nisso (precisa encontrar um link para fazer backup disso, mas me enferruja enquanto eu faço :-)

Resumo: não faça isso.

gbn
fonte
Desempenho quando a linha exceder 8060 bytes . Isso se refere aos bytes usados ​​reais e não aos bytes máximos permitidos?
18118 bernd_k
@bernd_k: 8060 = maior quantidade de dados para uma linha que cabe em uma única página 8192. Incluir sobrecarga de linha. Restante (132 bytes) = sobrecarga da página
gbn
Isso significa que o desempenho diminui quando o tamanho maior é realmente usado, não pelo simples fato de que é permitido.
5111 bernd_k
@bernd_k: qualquer queda no desempenho é causada por 1. alocação de memória para classificações etc. 2. Estouro de linha (> 8060 bytes). O fato de ter 10 caracteres em cada varchar (8000) é irrelevante até que essas condições sejam atendidas (o SQL avisa sobre possíveis erros posteriormente para chaves de índice)
gbn
Classificar uma tabela com uma coluna varchar (100) preenchida com campos de 100 bytes vale outra pergunta, porque a classificação assume em média 50 caracteres?
5111 bernd_k
7

Supondo que você esteja se referindo ao SQL Server, posso pensar em um.

Há um limite para o tamanho (8K) de uma linha em uma tabela e o SQL permite definir campos varchar que teoricamente poderiam exceder esse limite. Portanto, o usuário poderá obter erros se colocar muitos dados no campo relacionado a isso.

A partir do SQL 2K8, você pode exceder esse limite, mas há implicações no desempenho .

Além disso, há toda a verificação de razoabilidade de limitar o tamanho ao que você espera que os dados sejam. Se você deseja um campo de tamanho ilimitado, por que não usar texto ou ntext?

JohnFx
fonte
para que os tipos de dados texto e ntext sejam armazenados de uma maneira que não afete o desempenho?
Chad
Esses tipos não contribuem muito para o limite de tamanho de linha de 8K em uma tabela porque os dados reais são armazenados em uma tabela separada sob as capas, em vez de alinhados com o restante das colunas. Ainda há um impacto no desempenho, mas por diferentes razões. Há também limitações ao apoio recurso sobre estes campos quando comparado com varchar e nvarchar
JohnFx
text e ntext foram descontinuados em favor de varchar (max).
Phil Helmer
3

Certamente depende de quais informações estão sendo armazenadas no campo?

Algumas coisas terão um comprimento máximo por várias razões e, se tiver que haver um comprimento máximo, esse deverá ser o comprimento do seu campo.

Se teoricamente não houver comprimento máximo, eu questionaria por que o varchar seria usado.

Toby
fonte
3

No contexto dos bancos de dados Oracle, aprendi que sempre usar o menor tamanho de campo para colunas de banco de dados tem uma armadilha.

Ao mover dados por meio de exportação e importação de um banco de dados com agrupamento de byte único para outro com agrupamento de vários bytes (como Oracle XE), o comprimento em bytes pode aumentar e a importação dos dados para as tabelas criadas pela importação falha. Obviamente, a Oracle tem a opção de definir o comprimento do varchar2 como char ou como byte.

O que quero dizer aqui é que nem sempre é aconselhável definir um campo sempre o menor possível. Tenho visto muitas tabelas de alterações para aumentar o campo posteriormente (causado por requisitos alterados).

Ter 20% - 100% de campo não utilizado é uma opção discutível aqui.

bernd_k
fonte