varchar (255) vs tinytext / tinyblob e varchar (65535) vs blob / text

Por definição:

VARCHAR: O intervalo de comprimento é de 1 a 255 caracteres. Os valores VARCHAR são classificados e comparados sem distinção entre maiúsculas e minúsculas, a menos que a palavra-chave BINARY seja fornecida. x + 1 bytes
TINYBLOB, TINYTEXT: uma coluna BLOB ou TEXT com um comprimento máximo de 255 (2 ^ 8 - 1) caracteres x + 1 bytes

Portanto, com base nisso, crio a seguinte tabela:

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255),
  `lastname` tinytext,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

Ou é melhor criar um varchar ou tinytext e por quê ?

É o mesmo para:

VARCHAR: O intervalo de comprimento é> 255 caracteres. Os valores VARCHAR são classificados e comparados sem distinção entre maiúsculas e minúsculas, a menos que a palavra-chave BINARY seja fornecida. x + 2 bytes
BLOB, TEXT Uma coluna BLOB ou TEXT com um comprimento máximo de 65535 (2 ^ 16 - 1) caracteres x + 2 bytes

mysql

— Tech4Wilco
fonte

O VARCHAR precisa de menos sobrecarga de memória, mas geralmente serão totalmente lidos na memória, portanto, no final, o VARCHAR ainda pode usar mais memória. Ambos são diferentes. Você usa o BLOB para armazenar dados binários como uma imagem, áudio e outros dados multimídia. e VARCHAR para armazenar texto de qualquer tamanho até o limite.

— Livro de Zeus

Nesse caso, varcharé melhor.

Observe que varcharpode ser de 1 a 65535 caracteres.

Os valores nas colunas VARCHAR são sequências de comprimento variável. O comprimento pode ser especificado como um valor de 0 a 255 antes do MySQL 5.0.3 e 0 a 65.535 em 5.0.3 e versões posteriores. O comprimento máximo efetivo de um VARCHAR no MySQL 5.0.3 e posterior está sujeito ao tamanho máximo da linha (65.535 bytes, que é compartilhado entre todas as colunas) e ao conjunto de caracteres usado. Consulte a Seção E.7.4, “Contagem de colunas da tabela e limites de tamanho de linha”.

Os blobs são salvos em uma seção separada do arquivo.
Eles exigem um fileread extra para incluir nos dados.
Por esse motivo, o varchar é obtido muito mais rápido.

Se você tem um blob grande que não acessa com frequência, então um blob faz mais sentido.
Armazenar os dados de blob em um arquivo separado (parte do) permite que seu arquivo de dados principais seja menor e, portanto, obtido mais rápido.

— João
fonte

Se isso é melhor ou não, depende de seus padrões de acesso aos dados.

— Michael Mior

Que arquivo separado poderia ser?

— glglgl

Blobs não são salvos em um arquivo separado. Mas eles são armazenados em um local físico separado do resto das colunas.

— Michael Mior

Observe que isso não depende apenas da frequência de acesso, mas também de quais operações estão sendo realizadas nos dados. Por exemplo, qualquer consulta que requeira uma varredura de tabela (o que geralmente é ruim de qualquer maneira), mas não a coluna de texto, será agravada pelo maior volume de dados varridos.

— Michael Mior

Também suspeito que filesorts que não usam esta coluna podem ser mais eficientes se os dados forem armazenados fora da página, embora eu não tenha certeza de que o otimizador de consulta seja inteligente o suficiente para não extrair esses dados.

— Michael Mior