CHAR ou VARCHAR? Que tipo de campo escolher no MySQL?

Ambos os tipos de campo “texto” podem ser definidos com um comprimento máximo no MySQL. A principal diferença entre os dois tipos de campos é que o CHAR sempre armazenará o texto com o tamanho fixo, mesmo que o “texto” seja menor do que o tamanho máximo especificado na criação do campo. Neste caso, o próprio SGBD do MySQL irá usar espaços a direita do “texto” preenchendo o campo até a quantidade máxima especificada em sua criação. Note, que esses espaços serão removidos quando você recuperar os dados a armazenados.

Por outro lado, “textos” armazenadas em uma coluna VARCHAR exigem apenas o tamanho do “texto” armazenado. Portanto, a palavra “ivo” em uma coluna VARCHAR(10) irá requerer quatro bytes de espaço (o comprimento do “texto” mais 1), enquanto em uma coluna CHAR(10), a mesma palavra exigirá 10 bytes de espaço.

Assim, de modo geral, as colunas VARCHAR tendem a consumir menos espaço em disco do que colunas CHAR. Contudo, as bases de dados são normalmente mais rápidas quando se trabalha com colunas de tamanho fixo, o que é um argumento a favor de CHAR. E essa mesma palavra de três letras, “ivo”, em um CHAR(3) utiliza apenas 3 bytes, enquanto em um VARCHAR(10) requer 4. Desta forma, como decidir qual usar?

Se o “texto” for sempre de um tamanho determinado (por exemplo, uma abreviatura do estado), use CHAR, caso contrário, use VARCHAR. Você pode notar, porém, que, em alguns casos, o MySQL define uma coluna de um tipo (como CHAR) embora você a tenha criado como outro tipo (VARCHAR). Isto é perfeitamente normal e é a maneira que o MySQL possui para melhorar o desempenho.

OBS: Note que a palavra texto encontra-se marcada aqui no sentido de ressaltar que o campo “string” pode, além de conter caracteres, conter também números, datas ou listas armazenadas como texto (string). Neste caso, não poderão ser usadas as funções SQL de cálculo específicas de outros tipos. A não ser que sejam convertidas antes.

Fonte: PHP 6 and MySQL 5 for Dynamic Web Sites. ULLMAN, Larry, 2007.