Tipos de Dados MySQL Explicados: Escolha os Tipos de Coluna Ideais para Desempenho e Escalabilidade

1. Introdução: Por que Você Deve Entender a Lista de Tipos de Dados do MySQL

Quando você projeta tabelas ou integra aplicações com o MySQL, uma das perguntas mais comuns é: “Qual tipo de dado devo usar para esta coluna?”
Deve ser INT? Você realmente precisa de BIGINT? VARCHAR é suficiente para strings, ou TEXT é melhor? Essas escolhas podem parecer menores, mas formam a base que afeta seu sistema posteriormente.

Se você subestimar como escolher tipos de dados, frequentemente encontrará problemas como os seguintes:

• À medida que seus dados crescem além do esperado, você desperdiça espaço de armazenamento
• Índices incham e o desempenho das consultas degrada gradualmente
• Valores fora do intervalo ou overflow causam bugs ou exceções inesperadas
• Você é forçado a mudar os tipos de coluna mais tarde, desencadeando uma migração em grande escala

Em outras palavras, entender sistematicamente os tipos de dados do MySQL e escolher o correto para cada caso de uso é a maneira mais rápida de melhorar tanto o desempenho quanto a manutenibilidade.

Esta página destina‑se principalmente a leitores como:

• Engenheiros que estão prestes a iniciar desenvolvimento de sistemas sérios com MySQL
• Engenheiros de backend / infraestrutura que desejam revisar designs de tabelas existentes
• Desenvolvedores web e programadores que buscam “tipos recomendados” por caso de uso

Começaremos organizando os principais tipos de dados do MySQL como uma “lista” categorizada. Em seguida, explicaremos os tipos principais — numéricos, string, data/hora, JSON, ENUM/SET — abordando suas características, casos de uso típicos e dicas de seleção. Por fim, resumiremos erros comuns de design e como evitá‑los, juntamente com um FAQ.

Isso não é apenas uma “lista de termos”. É estruturado como orientação para tomada de decisão, para que você não fique preso ao projetar tabelas em projetos reais. Na próxima seção, vamos mergulhar em como pensar sobre tipos de dados e revisar a lista categorizada.

2. O Que é um Tipo de Dados e Por Que “Escolher o Tipo Certo” Importa?

Em um banco de dados, um “tipo de dado” é uma regra que define que tipo de valores uma coluna pode armazenar.
O MySQL oferece muitos tipos de dados — inteiros, decimais, strings, datas, binários, JSON e mais — portanto você precisa escolher adequadamente dependendo do seu objetivo.

O Papel dos Tipos de Dados

Um tipo de dado não é apenas uma “categoria de formato”. Ele desempenha múltiplos papéis ao mesmo tempo:

• Restringir o tipo de dado (numérico vs. string, boolean, etc.)
• Definir o intervalo permitido e o número de dígitos
• Determinar a memória necessária (tamanho de armazenamento)
• Influenciar estruturas de índice e desempenho de busca
• Afetar conversões implícitas e regras de comparação (ex.: collation de strings)

Em resumo, os tipos de dados não são meramente “contêineres” — são escolhas de design fundamentais que afetam todo o ciclo de vida da gestão de dados.

O Que Acontece Se Você Escolher o Tipo Errado?

Se você escolher o tipo de dado errado, problemas como estes ocorrem frequentemente no trabalho real:

• Desperdício de Armazenamento

Por exemplo, se BIGINT (8 bytes) é suficiente, mas você usa erroneamente DECIMAL ou LONGTEXT, pode consumir muito mais espaço em disco do que o esperado.

• Consultas Mais Lentas

Se você usar excessivamente buscas LIKE em colunas TEXT enormes, ou se os índices incharem porque você escolheu tipos numéricos excessivamente grandes, a execução do SQL tende a ficar mais lenta.

• Valores Inconsistentes ou Overflow

Você pode armazenar valores que não cabem em INT, causando valores negativos inesperados, arredondamento ou outros problemas.

• Alterações de Tabela de Alto Custo

Especialmente em tabelas grandes, mudar tipos com ALTER TABLE pode levar a:

• Longos tempos de bloqueio
• Impacto no serviço
• Trabalho de migração de dados e outros riscos.

Categorias Principais que Você Deve Entender Desde o Início

Os tipos de dados do MySQL são amplamente categorizados da seguinte forma:

• Tipos numéricos (inteiros, decimais)
• Tipos de string
• Tipos de data e hora
• Tipos binários
• Tipo JSON
• Tipos ENUM / SET
• Tipos de dados espaciais

Cada categoria tem diferentes trade-offs—forças/fraquezas, “leve vs. pesado” e “fácil vs. difícil de pesquisar”. É por isso que você precisa da seleção ótima de tipo para cada caso de uso.

3. Categorias de Tipos de Dados MySQL (Lista de Visão Geral)

Nesta seção, resumiremos os tipos de dados disponíveis no MySQL como uma lista de visão geral categorizada. Na prática, as primeiras coisas que você quer confirmar são “Quais tipos existem?” e “Qual devo usar?”
Então, aqui mostraremos claramente casos de uso, características principais e nomes de tipos representativos, e depois explicaremos cada categoria em mais detalhes nas seções seguintes.

3.1 Tipos Numéricos

Os tipos numéricos são a base para todo o processamento numérico, incluindo inteiros, decimais e valores de ponto flutuante.
Esta categoria é usada com mais frequência para IDs, quantidades, preços, verificações de flags e muitos outros propósitos.

Tipos Inteiros

Notas

• Adicionar UNSIGNED dobra o intervalo positivo.
• INT é usado em muitos casos, mas usar BIGINT casualmente pode tornar os índices mais pesados.

Tipos Decimais / Ponto Flutuante

Notas

• Para dinheiro, DECIMAL é a única escolha razoável . Tipos de ponto flutuante ( FLOAT / DOUBLE ) podem introduzir erros.
• Em casos envolvendo muitos cálculos, DOUBLE é às vezes escolhido por trade-offs de velocidade/precisão.

Outros Tipos Numéricos

3.2 Tipos de Data e Hora

O manuseio de data/hora é usado com muita frequência no desenvolvimento de aplicativos.
Dependendo do propósito, fatores como “comportamento de fuso horário”, “atualizações automáticas” e “precisão em nível de segundo” diferem, então escolher o tipo certo importa.

Notas

• Se você quiser gerenciar “atualizado em” automaticamente, TIMESTAMP é conveniente.
• Para “logs” ou “histórico” onde você quer armazenar timestamps precisos, DATETIME é comumente usado.

3.3 Tipos de String / Binário

Nomes de usuário, e-mails, senhas, descrições—strings são frequentemente a área mais complexa no design de tabelas.

Strings de Comprimento Fixo

Strings de Comprimento Variável

Texto Grande (Família TEXT)

Notas

• Use TEXT quando precisar armazenar strings muito grandes, como corpos de artigos ou descrições longas.
• Tenha cuidado com o design de pesquisa e índices.

Dados Binários (BINARY / BLOB)

※ Em geral, arquivos grandes não são armazenados no banco de dados; um design comum é armazená-los em armazenamento externo em vez disso.

Tipos ENUM / SET (Enumerações)

Notas

• Se você precisar alterar a definição do tipo mais tarde, a manutenção se torna pesada
• Pode ser eficaz para candidatos estáticos em pequena escala

3.4 Tipo JSON

• Você obtém flexibilidade semelhante ao NoSQL enquanto ainda pode usar funções específicas do JSON.
• No entanto, não é recomendado empacotar dados pesquisados frequentemente em JSON . Se puder ser normalizado, deve ser modelado como tabelas estruturadas.

3.5 Tipos Espaciais

Esses são usados ao trabalhar com dados geográficos e de localização.

Em aplicativos web típicos, esses não são usados com frequência, mas são importantes para apps de mapa e integrações de GPS.

4. Como Escolher e Usar Cada Tipo de Dados (Pontos de Decisão Chave)

Nesta seção, mergulhamos mais fundo nas categorias introduzidas acima, focando em “como escolher em cenários do mundo real”.
Apenas conhecer os nomes não é suficiente—selecionar o tipo de dados de melhor ajuste tem um impacto significativo na manutenibilidade, desempenho e escalabilidade futura.

4.1 Como Escolher Tipos Numéricos

Critérios para Escolher Tipos Inteiros

Ao selecionar tipos inteiros, foque nesses três pontos:

1. Entenda o Intervalo Máximo Necessário

• Contadores pequenos → TINYINT
• Quantidades de produtos / flags → SMALLINT / INT
• IDs em grande escala ou logs → BIGINT

Alguns projetos usam BIGINT em excesso para chaves primárias, mas isso pode facilmente levar a tamanhos de índice maiores e pode impactar negativamente o desempenho.

2. Considere Ativamente UNSIGNED

Se você lida apenas com valores positivos (por exemplo, IDs numéricos, contagens de inventário)
→ usar UNSIGNED dobra o intervalo e pode permitir que você use um tipo menor.

3. Para Valores Monetários ou Críticos de Precisão, Use DECIMAL

Para valores onde “erros não são aceitáveis”, evite FLOAT/DOUBLE e sempre use DECIMAL.

4.2 Como Escolher Tipos de Data e Hora

O tipo apropriado depende do seu caso de uso.

Diferenças Entre DATETIME e TIMESTAMP

Regras Gerais para Escolher

• Logs de aplicação ou registros de eventos → DATETIME (evita efeitos de conversão de fuso horário)
• Quando você deseja registrar timestamps atualizados automaticamente → TIMESTAMP (comportamento conveniente de auto‑atualização)

Onde YEAR É Útil

• Categorias de ano fiscal, anos de lançamento, anos de fundação, etc. → Gerencie de forma compacta (1 byte)

4.3 Como Escolher Tipos de String

Como Decidir Entre CHAR e VARCHAR

Quando Você Deve Usar CHAR

• O comprimento é sempre constante: códigos de província, códigos de país, identificadores de comprimento fixo, etc.
• Dados que precisam de acesso rápido e são atualizados raramente

Quando Você Deve Usar VARCHAR

• O comprimento varia: nomes, endereços de e‑mail, títulos, etc.
• A melhor escolha padrão na maioria das situações

Você Deve Usar TEXT?

Vantagens do TEXT

• Suporta texto grande (descrições, corpos de artigos, etc.)

Cuidados com TEXT

• Indexação é limitada (índices de prefixo são necessários)
• O desempenho pode degradar quando usado em JOINs ou cláusulas WHERE
• Busca e ordenação podem ser pesadas

Recomendação:
Use TEXT para “strings grandes” como corpos ou notas,
e use VARCHAR tanto quanto possível para todo o resto.

4.4 Como Escolher o Tipo JSON

O tipo JSON é muito útil, mas você precisa usá‑lo “corretamente”.

Quando JSON Funciona Bem

• Configurações flexíveis ou dados com número variável de campos
• Casos de uso de busca limitada, ou quando a aplicação o expande/analisa
• Armazenamento de dados leves que não requerem uma tabela mestre

Quando JSON Não É Adequado

• Dados que você pesquisa frequentemente
• Dados usados para buscas filtradas, agregação ou JOINs
• Dados estruturados que deveriam ser normalizados

Regra prática:
Dados que você precisa pesquisar devem ser normalizados e tratados como estrutura.
Não se esqueça de que JSON é “flexível, mas fraco para busca”.

4.5 Como Escolher Tipos ENUM / SET

Quando ENUM É Apropriado

• Estados são fixos: por exemplo, status (draft / published / archived)
• Um pequeno conjunto de opções que raramente muda

Cuidados com ENUM

• Adicionar ou mudar valores requer ALTER TABLE
• Risco de perder consistência com definições do lado da aplicação

Quando SET É Apropriado

• Dados de pequena escala que requerem seleção múltipla (por exemplo, dias da semana disponíveis, ou quando há apenas algumas opções de tags)

Cuidados com SET

• Combinações de valores podem se tornar complexas
• Gerenciar estados de múltiplos valores pode se tornar difícil

4.6 Como Escolher Tipos Binary / BLOB

BINARY / VARBINARY

• Tokens, IDs, valores de hash, etc.
• Binário de comprimento fixo (por exemplo, UUIDs de 16 bytes)

Casos de Uso Típicos para Tipos BLOB

• Arquivos pequenos, imagens em miniatura, dados criptografados

Mas Observe

• Armazenar arquivos grandes no banco de dados torna os backups mais pesados
• A carga de leitura/escrita também aumenta → Em sistemas reais, recomenda‑se armazenamento externo + gerenciamento de caminhos

5. Prática: Como Usar a “Lista de Referência de Tipos de Dados” ao Projetar Tabelas

Nesta seção, explicaremos como usar a lista de tipos de dados do MySQL em um fluxo de trabalho prático ao projetar tabelas.
Em vez de apenas memorizar tipos, organizar “por que você escolhe esse tipo” por meio de lógica e etapas leva a um design de banco de dados de maior qualidade.

5.1 Etapa 1: Clarificar o “Propósito” e a “Natureza” da Coluna

Primeiro, defina claramente o que será armazenado na coluna.

Lista de Verificação

• É numérico, string, data ou um indicador?
• É de comprimento variável ou fixo?
• Qual é o valor máximo ou o comprimento máximo?
• NULL deve ser permitido?
• É provável que cresça no futuro?

Se você prosseguir com suposições vagas aqui, a escolha do tipo se tornará desnecessariamente complicada mais tarde.

5.2 Passo 2: Estime o Intervalo e Formato Necessários

Em seguida, estime os limites superior/inferior, comprimento de caracteres e precisão necessária dos valores que você armazenará.

Exemplo: Coluna ID

• O número máximo de registros chegará a dezenas de milhões? Centenas de milhões? → Isso ajuda a determinar se INT é suficiente ou se BIGINT é necessário.

Exemplo: Nome do Produto

• Média de 15–25 caracteres, máximo em torno de 50? → VARCHAR(50) é suficiente. TEXT é desnecessário.

Exemplo: Preço

• É necessária precisão? → Você deve selecionar algo como DECIMAL(10,2) .

5.3 Passo 3: Considere o Volume de Dados e o Desempenho

Escolher tipos de dados MySQL impacta diretamente o desempenho.

Considerações Principais

• Tipos muito grandes → consomem armazenamento e tornam os índices mais pesados
• TEXT / BLOB → degradam o desempenho de busca
• JSON → flexível, mas fraco para buscas
• TIMESTAMP → eficiente para atualizações automáticas e comparações

Em particular, colunas com índices devem usar o tipo de dado mais leve possível.

5.4 Passo 4: Valide os Tipos com Dados de Exemplo

Depois de projetar a tabela, insira dezenas a centenas de linhas de dados de teste e verifique o comportamento.

O que Verificar

• Existem problemas inesperados de arredondamento ou truncamento?
• VARCHAR é suficiente, ou deveria ser TEXT ?
• A ordenação e busca de datetime se comportam como esperado?
• Desempenho de leitura/gravação de JSON

Testar com dados realistas reduz os “erros teóricos”.

5.5 Passo 5: Considere Escalabilidade e Manutenibilidade

Na fase final do design da tabela, verifique se mudanças futuras serão fáceis.

Exemplos de Mudanças de Tipo Pesadas

• ENUM (requer ALTER TABLE ao adicionar valores)
• TEXT → VARCHAR (expandir é fácil, reduzir é arriscado)
• FLOAT → DECIMAL (pode mudar a semântica)

Escolha tipos avaliando se a expansão futura é provável.

5.6 Passo 6: Exemplo CREATE TABLE (Amostra Prática)

Abaixo está uma tabela de exemplo que reflete padrões comuns de seleção de tipos de dados em uma aplicação web típica.

CREATE TABLE products (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name         VARCHAR(100) NOT NULL,
    price        DECIMAL(10,2) NOT NULL,
    stock        INT UNSIGNED NOT NULL DEFAULT 0,
    status       ENUM('draft', 'published', 'archived') NOT NULL DEFAULT 'draft',
    description  TEXT,
    created_at   DATETIME NOT NULL,
    updated_at   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Pontos Principais Neste Exemplo

• id : Usa BIGINT UNSIGNED considerando escala futura
• name : String variável de comprimento médio → VARCHAR
• price : Valor monetário → DECIMAL preciso
• stock : Contagem de estoque → INT UNSIGNED
• status : Conjunto fixo de valores → ENUM
• description : Texto potencialmente longo → TEXT
• updated_at : TIMESTAMP conveniente de atualização automática

Como mostrado, cada escolha de tipo deve ter uma justificativa clara, e ser capaz de articular esse raciocínio é uma marca de bom design.

6. Erros Comuns e Como Evitá‑los

Como o MySQL oferece muitos tipos de dados, vários erros comuns aparecem frequentemente em projetos reais. Esta seção destaca armadilhas típicas e fornece contramedidas práticas.

6.1 Usando Tipos de Dados Excessivamente Grandes

Exemplos Comuns

• Definir todos os IDs como BIGINT
• Definir todas as strings como VARCHAR(255)
• Usar TEXT para conteúdo não textual

Problemas

• Armazenamento desperdiçado
• Índices inchados que prejudicam o desempenho de consultas
• Largura de banda de rede desperdiçada (transferências de dados maiores)

Como Evitar

• Estime os valores máximos e mínimos com antecedência
• Defina os comprimentos de VARCHAR com base em evidências
• Use TEXT somente quando realmente necessário

6.2 Usando FLOAT/DOUBLE para Valores Decimais (Problemas de Precisão)

Exemplos Comuns

• Armazenar preços como FLOAT
• Comparações numéricas falham devido a erros de arredondamento

Como Evitar

• Use DECIMAL para dinheiro e valores críticos de precisão
• Evite FLOAT / DOUBLE exceto para cálculos científicos ou temporários

6.3 Colunas VARCHAR Superdimensionadas

Exemplos Comuns

• Usar VARCHAR(255) como padrão
• Definir comprimentos grandes para colunas que armazenam apenas cerca de 30 caracteres

Problemas

• Memória e armazenamento desperdiçados
• Índices costumam ficar mais pesados

Como Evitar

• Estime os comprimentos médio e máximo a partir dos dados reais
• Evite tamanhos desnecessariamente grandes (por exemplo, endereços de e‑mail → VARCHAR(100) )

6.4 Uso Excessivo de Tipos TEXT

Exemplos Comuns

• Presumir que “string = TEXT”
• Usar TEXT para dados que precisam de filtragem ou busca

Problemas

• Muitas limitações de indexação
• Pesadas buscas LIKE
• Processamento mais lento em JOINs

Como Evitar

• Use TEXT somente para conteúdo extenso, como descrições ou corpos de texto
• Armazene strings pesquisáveis em VARCHAR sempre que possível

6.5 Escolhendo Tipos Date/Time Sem Entender Suas Propriedades

Exemplos Comuns

• Usar DATETIME para tudo
• Usar DATETIME para “updated at”, de modo que não atualize automaticamente
• Timestamps mudam devido a diferenças de fuso horário

Como Evitar

• Necessita de atualização automática: TIMESTAMP
• Quer evitar mudanças de fuso horário: DATETIME
• Precisa apenas do ano: YEAR

6.6 Usando ENUM / SET de Forma Muito Casual

Exemplos Comuns

• Usar ENUM mesmo que as opções possam mudar no futuro
• Usar SET como uma lista separada por vírgulas

Problemas

• Alterações exigem ALTER TABLE
• Inconsistência com definições do lado da aplicação torna‑se mais provável

Como Evitar

• Se os valores podem aumentar, gerencie‑os em uma tabela mestre separada
• Use ENUM somente quando o conjunto for pequeno e realmente fixo

6.7 Empacotar Demais em JSON “Por Conveniência”

Exemplos Comuns

• Empacotar estruturas que deveriam ser normalizadas em JSON
• Armazenar dados frequentemente pesquisados dentro de JSON

Problemas

• O desempenho de busca degrada
• Índices são menos eficazes / mais difíceis de usar
• Mais trabalho de parsing no lado da aplicação
• Design sem esquema facilita a quebra de consistência

Como Evitar

• Use JSON somente para dados que você não pesquisa
• Limite a “dados pequenos e variáveis”, como configurações
• Normalize informações usadas em JOINs e buscas

6.8 Subestimando o Custo das Alterações de Tipo

Problemas

• ALTER TABLE pode ser extremamente pesado em tabelas grandes
• Pode ocorrer tempo de inatividade do serviço ou longos períodos de bloqueio
• Em alguns casos, a migração de dados é necessária

Como Evitar

• Planeje o crescimento futuro durante a fase de design
• Use ENUM com cautela
• Deixe margem na precisão/escala do DECIMAL (mas não exagere)

7. Resumo

O MySQL oferece uma ampla variedade de tipos de dados, e o tipo que você escolher pode afetar significativamente desempenho, escalabilidade e manutenibilidade.
Especialmente em ambientes como aplicações web, onde os dados tendem a crescer, decisões de design antecipadas impactam diretamente a qualidade a longo prazo.

Principais Conclusões deste Artigo

• Tipos de dados são fatores críticos que afetam “tipo de valor, intervalo, precisão, armazenamento e desempenho.”
• Tipos numéricos, de string, data/hora, JSON, ENUM/SET e BLOB têm cada um seus pontos fortes e fracos.
• Inteiros, strings e tipos de data/hora são os mais usados, portanto escolher corretamente é importante.
• JSON e ENUM são convenientes, mas o uso indevido pode dificultar a manutenção.
• O uso excessivo de TEXT e BLOB pode degradar o desempenho.
• Uma abordagem de design racional é: “Propósito → Intervalo → Desempenho → Escalabilidade.”

Uma Lista de Verificação de Design que Você Pode Usar a Partir de Hoje

• O propósito da coluna está claramente definido?
• Você entende os valores máximos e mínimos possíveis?
• Há evidências por trás do comprimento VARCHAR escolhido?
• Você está usando DECIMAL para dinheiro?
• Os timestamps “updated at” são gerenciados com TIMESTAMP e auto‑atualização quando apropriado?
• Antes de usar ENUM, você considerou se os valores podem aumentar no futuro?
• Você está evitando designs onde a busca se torna lenta devido ao uso excessivo de JSON?
• Você projetou para evitar operações pesadas de ALTER TABLE em grandes conjuntos de dados?

Finalmente

Não há sempre uma única “resposta correta” ao escolher tipos de dados MySQL.
Entretanto, se você escolher com propósito e pensando no crescimento futuro, pode prevenir problemas graves e manter sua estrutura de dados limpa.

Em última análise, a melhor escolha depende da natureza do seu projeto, do volume de dados e dos requisitos da aplicação. Mas se você usar os critérios apresentados neste artigo como base, deverá ser capaz de fazer escolhas de tipos de dados melhores em qualquer situação.

Em seguida, apresentaremos uma seção de FAQ que resume perguntas frequentemente feitas no trabalho real. Quando você não tem certeza sobre a seleção de tipos, consultar este FAQ primeiro ajudará a decidir de forma mais tranquila.

8. FAQ

Escolher tipos de dados MySQL é uma área onde as decisões podem variar significativamente dependendo da experiência prática. Aqui compilamos perguntas comuns das equipes de desenvolvimento e fornecemos respostas curtas e claras.

Q1. Devo usar INT ou BIGINT?

R: Use INT por padrão. Use BIGINT somente se puder exceder 2,1 bilhões no futuro.

INT (4 bytes) suporta até cerca de 2,1 bilhões e é suficiente para a maioria das aplicações. Considere BIGINT para logs, serviços de alto tráfego ou sistemas que possam gerar números de IDs extremamente grandes.

Q2. Devo usar VARCHAR ou TEXT?

R: Use VARCHAR se precisar de buscas. Use TEXT para conteúdo extenso.

• VARCHAR : Amigável a índices e melhor para buscas
• TEXT : Bom para conteúdo longo, mas não ideal para buscas ou JOINs

※ O uso excessivo de TEXT pode levar à degradação de desempenho.

Q3. É aceitável armazenar dinheiro como DOUBLE?

R: Não. Sempre use DECIMAL.

DOUBLE e FLOAT podem introduzir erros de arredondamento, portanto não são adequados para dinheiro ou valores críticos de precisão. Em sistemas de negócios, DECIMAL(10,2) ou DECIMAL(12,2) é um padrão comum.

Q4. Não entendo a diferença entre DATETIME e TIMESTAMP. Como devo escolher?

R: Use TIMESTAMP se precisar de auto‑atualizações. Use DATETIME se precisar armazenar um timestamp preciso sem conversão de fuso horário.

• TIMESTAMP : Auto‑atualização e conversão de fuso horário
• DATETIME : Não afetado por fusos horários; armazena a data/hora “como está”

DATETIME é frequentemente usado para logs e tabelas de histórico.

Q5. É seguro usar ENUM?

R: É útil apenas quando os valores são “garantidos que não mudarão”.

ENUM é leve e conveniente, mas adicionar ou mudar valores requer ALTER TABLE. Para campos que podem crescer, recomenda‑se gerenciamento mestre em uma tabela separada.

Q6. Posso simplesmente usar JSON por enquanto?

R: Use JSON apenas para dados que você não pesquisa. Dados que você pesquisa devem ser normalizados.

JSON é flexível, mas tem fraquezas de desempenho.

• Fraco para buscas
• Estruturas de índice tornam‑se mais complexas
• Mais difícil manter a consistência dos dados

Funciona bem para configurações e opções — atributos que não são usados como condições de busca.

Q7. Como devo decidir o comprimento máximo para VARCHAR?

R: Estime o máximo com base em dados reais e adicione uma pequena margem.

Exemplo: Endereço de e‑mail → VARCHAR(100) é suficiente
Exemplo: Nome de usuário → VARCHAR(50) costuma ser adequado

“255 só porque” não é recomendado.

Q8. Se eu escolher o tipo errado, posso mudá‑lo depois?

R: Sim, mas pode ser muito pesado em tabelas grandes.

ALTER TABLE frequentemente envolve varreduras completas e reconstruções, o que pode causar tempo de inatividade ou longos bloqueios.

→ Um planejamento cuidadoso na fase de design inicial é o mais importante.