Início / dba / Perguntas / 227088
Accepted
dbdemon
Asked: 2019-01-15 05:47:54 +0800 CST

Comprimento da coluna varchar - há uma vantagem em usar 255? [duplicado]

  • 772

Muitas vezes me deparo com colunas que são varchar(255), então presumivelmente isso é uma espécie de convenção. 255 é 2^8 - 1. Então, há algo 'mágico' sobre comprimentos que são 2^n - 1? Ou apenas especificamente 255? Existe uma vantagem de otimização de desempenho ou armazenamento para determinados varcharcomprimentos específicos? Ou isso é apenas uma velha sabedoria que não é mais aplicável às versões atuais do MariaDB e MySQL?

mysql mariadb

4 respostas

  1. Best Answer

    Eu discuto contra 255 ocasionalmente. Claro, costumava haver alguns motivos para '255', mas muitos não são mais válidos e até contraproducentes.

    No MySQL, há razões para parar em 191, 255, 767, 3071, 64K e provavelmente outros valores. Alguns dependem do Engine, outros do CHARACTER SET, etc.

    A VARCHARé armazenado como um comprimento de 1 ou 2 bytes mais bytes suficientes para o texto atual em qualquer conjunto de caracteres que você especificou. No entanto, a escolha de 1 ou 2 não é determinada apenas pela coluna individual; é orientado pelo tamanho total da linha. Ou seja, essa não é uma desculpa válida para usar 255.

    Use um comprimento que seja

    • Grande o suficiente para nunca ser excedido de forma conservadora, mas
    • Tão pequeno quanto parece razoável.

    Enquanto estou reclamando... CHAR( comprimento fixo ) raramente é aconselhado. E quase sempre deve ser CHARACTER SET ascii-- country_code, postal_code, S/N, M/F, MD5, UUID, base64, etc. (MD5 e UUID devem ser levados um passo adiante, mas isso é outro discurso).

    Potenciais impactos negativos do uso cego de '255':

    • Se você tiver muitas colunas, poderá atingir um limite máximo de tamanho de linha e CREATE TABLEfalhará.
    • Você pode estourar um limite no tamanho do índice.
    • Complex SELECTspode precisar de uma tabela temporária e pode ser usado MEMORYpara isso. Nesse caso, VARCHAR(255)torna -se CHAR(255)para a tabela temporária. E, se estiver usando utf8, são 755 bytes para cada linha! (8.0 corrige esta falha de design?)

    Relacionado: Não use cegamente BIGINTpara todos os números. Leva 8 bytes. Mesmo INTé um exagero, em 4 bytes. Veja MEDIUMINT, SMALLINTe TINYINT. Esteja ciente de que o (2)on INT(2)não significa nada; ainda leva 4 bytes.

    • 8

  2. Em um ponto no tempo, esse era o comprimento máximo de uma coluna no Sybase e o SQL Server derivado. Tenho certeza de que outros copiaram para manter a compatibilidade para que a migração de aplicativos / SQL para uma nova plataforma não fosse difícil, pois todos estavam lutando por participação de mercado na época.

    Não há nenhuma boa razão para perpetuá-lo, além da compatibilidade. Percebi que parece ter sido substituído por varchar(max) nos dias de hoje.

    • 5

  3. Comprimentos de coluna "padrão" são usados ​​em todos os lugares e invariavelmente indicam que não houve esforço realizado para entender o comprimento real necessário da coluna.

    Se você tem uma coluna onde nunca haverá mais de 24 caracteres usados, por que especificar o comprimento da coluna como 255?

    Analisar e usar o comprimento correto para colunas de comprimento variável exige um pouco de esforço e garante que os efeitos colaterais do uso de um comprimento de coluna muito grande nunca se tornem um problema. Eu sei que sua pergunta é sobre o MySQL, no entanto, esta resposta mostra como o SQL Server usa comprimentos de coluna de várias maneiras que podem não ser aparentes no início.

    • 2

  4. Nós adotamos uma regra completamente diferente agora. Usamos uma de duas coisas:

    `NVARCHAR(max)`

    se não for indexado.

    `NVARCHAR(400)`

    se for indexado.

    De um modo geral, acreditamos que os limites são obsoletos e realmente não devemos nos importar mais. O espaço em disco é barato. O 400 garante que o índice sempre possa ser criado na plataforma de destino mais restritiva. É do meu entendimento que o limite de índice de 255 no MySQL se foi, senão eu teria escrito 255. A questão VARCHARé que você não será penalizado por permitir que ele seja maior do que o necessário, então não há muita desvantagem em ser muito grande, então nós apenas configuramos grande e não pensamos mais nisso.

    • -1

relate perguntas