Isso depende inteiramente do mecanismo DBMS que está sendo usado. O próprio SQL não determina como as coisas são armazenadas fisicamente, apenas como elas são vistas logicamente.

Por exemplo, seu DBMS pode alocar espaço na linha para o tamanho máximo, além de alguns bytes extras para armazenar o tamanho. Nesse caso, haveria uma grande diferença entre varchar(10) e varchar(1000) já que você desperdiçaria um pouco de espaço por linha.

Alternativamente, ele pode usar um buffer pool para o varchar dados e armazenar apenas o comprimento e o "endereço inicial" do conjunto de buffers na linha. Nesse caso, cada linha armazenaria informações de tamanho idêntico para um varchar coluna independentemente de seu tamanho, mas haveria uma etapa adicional para extrair os dados reais nessa coluna (seguindo o link para o conjunto de buffers).

O motivo pelo qual você usa um varchar é exatamente por isso que se chama varchar . Ele permite que você armazene elementos de dados de tamanho variável. Normalmente, char(10) dá-lhe dez caracteres, não importa o que, preenchendo-o com espaços se você inserir algo mais curto. Você pode cortar os espaços finais ao extraí-los, mas isso não funcionará tão bem se os dados que você deseja armazenar forem realmente "hello " , com um espaço à direita que você deseja preservar.

Um mecanismo DBMS decente pode decidir fazer uma troca dependendo do tamanho máximo do varchar coluna. Para os curtos, ele poderia apenas armazená-lo em linha na linha e consumir os bytes extras para o tamanho.

varchar mais longo as colunas podem ser "terceirizadas" para um conjunto de buffers separado para garantir que a leitura de linha seja mantida eficiente (pelo menos até que você precisa o grande varchar coluna, de qualquer maneira).

O que você precisa fazer é refazer a pergunta para seu DBMS específico para obter uma resposta mais direcionada.

Ou, com toda a honestidade, projete seu banco de dados para armazenar apenas o tamanho máximo. Se você sabe que é 10, então varchar(1000) é um desperdício. Se, no futuro, você precisar aumentar a coluna, isso é a hora de fazer isso, e não agora (consulte YAGNI ).

Para MySQL, você vai querer ver Chapter 14 Storage Engines da documentação online.

Abrange os vários mecanismos de armazenamento (como InnoDB e MyISAM) que o MySQL usa e, olhando profundamente o suficiente, você pode ver como as informações são armazenadas fisicamente.

Por exemplo, em MyISAM, a presença de dados de comprimento variável em uma tabela (varchar incluído) geralmente significa tabelas dinâmicas . Isso segue um esquema aproximadamente análogo ao conceito de buffer pool que mencionei acima, com a vantagem de que menos espaço é desperdiçado para colunas de tamanho variável e a desvantagem de que as linhas podem ficar fragmentadas.

O outro formato de armazenamento (descontando o formato compactado, pois ele é realmente usado apenas para tabelas somente leitura) é o estático , onde os dados são armazenados em uma única linha física.

Informações sobre as estruturas físicas do InnoDB podem ser encontradas aqui . Dependendo se você usa o formato de arquivo Antelope ou Barracuda, você acaba com a situação "todas as informações são uma linha física" ou "pool de buffers", semelhante à distinção do MyISAM entre dinâmico e estático.