it-swarm.dev

Comprimentos do MySQL VARCHAR e UTF-8

No MySQL, se eu criar um novo campo VARCHAR(32) em uma tabela UTF-8, isso significa que posso armazenar 32 bytes de dados nesse campo ou 32 caracteres (multi-byte)?

70
Alix Axel

Essa resposta apareceu no topo dos meus resultados de pesquisa do Google, mas não estava correta:

A confusão é provavelmente devida a diferentes versões do mysql sendo testadas.

  • Versão 4 conta bytes
  • Versão 5 conta caracteres

http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html

O MySQL interpreta as especificações de comprimento nas definições de coluna de caracteres em unidades de caracteres. (Antes do MySQL 4.1, os comprimentos das colunas eram interpretados em bytes.) Isso se aplica aos tipos CHAR, VARCHAR e TEXT. 

Curiosamente (eu não tinha pensado nisso) o comprimento máximo de uma coluna varchar é afetado por utf8 da seguinte forma:

O comprimento máximo efetivo de um VARCHAR no MySQL 5.0.3 e posterior está sujeito ao tamanho máximo de linha (65.535 bytes, que é compartilhado entre todas as colunas) e ao conjunto de caracteres utilizado. Por exemplo, os caracteres utf8 podem exigir até três bytes por caractere, portanto, uma coluna VARCHAR que usa o conjunto de caracteres utf8 pode ser declarada com um máximo de 21.844 caracteres. 

154
M Brown

permitiria que você armazenasse 32 caracteres de múltiplos bytes

Para economizar espaço com UTF-8, use VARCHAR em vez de CHAR. Caso contrário, O MySQL deve reservar três bytes para Cada caractere em uma coluna utf8 CHAR CHAR CHARACTER SET Porque esse é o comprimento máximo possível de . Por exemplo, O MySQL deve reservar 30 bytes para uma coluna CHAR (10) CHARACTER SET utf8.

http://dev.mysql.com/doc/refman/5.0/en/charset-unicode.html

8
jspcal

32multibytesdata para varchar(32) com collation utf8_unicode_ci, acabei de testar com o XAMPP.

1234567890123456789012345678901234567890

Seja truncado para:

12345678901234567890123456789012

Tenha em mente que estes caracteres não são regulares ASCII.

5
YOU

É melhor usar "char" para tabelas de atualização de alta frequência porque o comprimento total de dados da linha será fixo e rápido. As colunas Varchar tornam os tamanhos de dados de linha dinâmicos. Isso não é bom para o MyISAM, mas eu não sei sobre o InnoDB e outros. Por exemplo, se você tiver uma coluna de "tipo" muito estreita, talvez seja melhor usar char (2) com charset latin1 para reivindicar apenas um espaço mínimo. 

1
Nudge

Se você se conectar ao banco de dados usando a codificação latin1 (por exemplo, com PHP) para salvar uma string UTF8 PHP em uma coluna MySQL UTF8, você terá uma codificação UTF8 dupla.

Se a string UTF8 $s tiver 32 caracteres, mas 64 bytes e a coluna for VARCHAR(32) UTF8, a codificação dupla converterá a string $s em uma string UTF8 de 64 caracteres que será truncada no banco de dados para seus 32 primeiros caracteres correspondentes à string 32 primeiros bytes de $s. Você pode acabar pensando que o MySQL 5 se comporta como o MySQL 4, mas na verdade é uma segunda causa para o mesmo efeito. 

0
Laurent Lyaudet