Qual é a diferença entre os tipos de dados MySQL VARCHAR e TEXT?

dividido ligado a algumas informações que explicam o problema básico (há diferenças de desempenho), mas não é simples o suficiente dizer que um é sempre melhor que o outro. (caso contrário, não haveria razão para ter ambos.) Além disso, no MyISM, o tamanho máximo de 64k para VARCHAR não é por campo -- é por registro.

Basicamente, existem 4 maneiras de armazenar strings em registros de banco de dados:

1. comprimento fixo
2. Strings de estilo C (marcadas com um caractere NULL ou similar no final da string)
3. Strings de estilo Pascal (alguns bytes para indicar o comprimento, depois a string)
4. Ponteiros (armazenar a string em outro lugar)

MyISM usa algo semelhante ao #3 para VARCHAR e uma abordagem híbrida para TEXT onde armazena o início da string no registro e o restante da string em outro lugar. O InnoDB é semelhante para VARCHAR, mas armazena o campo TEXT completo fora do registro.

Com 1 e 4, as coisas no registro são sempre do mesmo tamanho, então é mais fácil pular se você não precisar da string, mas precisar de coisas depois dela. Tanto o #2 quanto o #3 não são tão ruins para strings curtas... #2 tem que continuar procurando o marcador, enquanto o #3 pode pular adiante... caso.

Se você realmente precisa ler a string, #4 é mais lento, pois você tem que ler o registro e depois ler a string que pode estar armazenada em outro lugar no disco, dependendo de como o banco de dados lida com isso. O nº 1 é sempre bem direto e, novamente, você se depara com problemas semelhantes, onde o nº 2 fica pior quanto maior a corda, enquanto o nº 3 é um pouco pior que o nº 2 para cordas muito pequenas, mas melhor à medida que fica mais longa.

Depois, há requisitos de armazenamento ... # 1 é sempre um comprimento fixo, portanto, pode ter inchaço se a maioria das strings não tiver o comprimento máximo. #2 tem 1 byte extra; #3 normalmente tem 2 bytes extras se comprimento máximo = 255, 4 bytes extras se um comprimento máximo de 64k. #4 tem o comprimento do ponteiro, mais as regras para #3 normalmente.

Para as implementações específicas no MySQL 5.1, os documentos do estado do MyISM :

• Suporte para um tipo VARCHAR verdadeiro; uma coluna VARCHAR começa com um comprimento armazenado em um ou dois bytes.
• Tabelas com colunas VARCHAR podem ter comprimento de linha fixo ou dinâmico.
• A soma dos comprimentos das colunas VARCHAR e CHAR em uma tabela pode ser de até 64 KB.

Enquanto para InnoDB :

• A parte de comprimento variável do cabeçalho do registro contém um vetor de bits para indicar colunas NULL. Se o número de colunas no índice que pode ser NULL for N, o vetor de bits ocupará CEILING(N/8) bytes. (Por exemplo, se houver de 9 a 15 colunas que podem ser NULL, o vetor de bits usa dois bytes.) As colunas que são NULL não ocupam espaço além do bit nesse vetor. A parte de comprimento variável do cabeçalho também contém os comprimentos das colunas de comprimento variável. Cada comprimento leva um ou dois bytes, dependendo do comprimento máximo da coluna. Se todas as colunas no índice forem NOT NULL e tiverem um comprimento fixo, o cabeçalho do registro não terá parte de comprimento variável.
• Para cada campo de comprimento variável não NULL, o cabeçalho do registro contém o comprimento da coluna em um ou dois bytes. Dois bytes só serão necessários se parte da coluna for armazenada externamente em páginas de estouro ou o comprimento máximo exceder 255 bytes e o comprimento real exceder 127 bytes. Para uma coluna armazenada externamente, o comprimento de dois bytes indica o comprimento da parte armazenada internamente mais o ponteiro de 20 bytes para a parte armazenada externamente. A parte interna tem 768 bytes, então o comprimento é 768+20. O ponteiro de 20 bytes armazena o comprimento real da coluna.

...

como acontece com tantas outras coisas ao lidar com bancos de dados, se você não tiver certeza do que é melhor para suas necessidades, tente comparar com dados e uso semelhantes e veja como eles se comportam.

Quando um SELECT precisa criar uma tabela temporária (como para classificar os resultados), ele criará uma tabela MEMORY ou uma tabela MyISAM. A MEMÓRIA é mais eficiente. Existem restrições em MEMORY -- uma delas é não permitir TEXT e BLOB. Portanto, um SELECT pode ser executado mais lentamente com TEXT do que VARCHAR.