MySQL na prática: o guia definitivo para escolher, escalar e confiar

Toda semana alguém me manda a mesma pergunta em alguma variação: "Ale, MySQL ainda serve?". A resposta curta é sim. A resposta honesta é: depende do que você vai fazer com ele — e é exatamente isso que este guia resolve.

Eu trabalho com banco de dados há mais de duas décadas, dei treinamento oficial de MySQL e Oracle para mais de mil alunos e já levantei (e derrubei, confesso) ambientes de produção o suficiente para ter cicatriz. O que vem abaixo não é folheto de fabricante: é o que costuma acontecer de verdade.

O mapa deste cluster de conteúdo

Esta página é o ponto de partida. Cada pergunta grande tem um artigo próprio, com benchmark de bolso, código e o que eu faria no lugar de quem pergunta:

• MySQL ou MariaDB: qual é o melhor? — o fork virou outro banco. Onde isso te ajuda e onde te morde.
• MySQL ou PostgreSQL: qual escolher? — comparativo sem torcida organizada.
• MySQL ou SQL: qual a diferença? — a pergunta mais comum e mais mal formulada da internet.
• Tenho muitos dados, posso usar MySQL? — limites reais, particionamento e sharding.
• MySQL em aplicações críticas e escaláveis — replicação, failover e RPO/RTO.

O que o MySQL é, de fato

MySQL é um SGBD relacional open source criado em 1995, hoje mantido pela Oracle, com duas engines que importam: InnoDB (transacional, ACID, padrão desde a versão 5.5) e MyISAM (legado — se você ainda usa em tabela nova, precisamos conversar).

Um teste de sanidade que eu rodo em qualquer servidor que chega na minha mão:

SELECT VERSION() AS versao,
       @@default_storage_engine AS engine_padrao,
       @@innodb_buffer_pool_size / 1024 / 1024 / 1024 AS buffer_pool_gb,
       @@transaction_isolation AS isolamento;

-- Tabelas que ainda estão no MyISAM (dívida técnica escondida)
SELECT table_schema, table_name, engine, ROUND(data_length/1024/1024) AS mb
FROM information_schema.tables
WHERE engine = 'MyISAM'
  AND table_schema NOT IN ('mysql','sys','information_schema','performance_schema')
ORDER BY data_length DESC;

Se o innodb_buffer_pool_size estiver no padrão de fábrica (128 MB) num servidor com 64 GB de RAM, você não tem um problema de banco lento: tem um problema de configuração. Já vi consultoria inteira ser contratada para resolver isso.

As três perguntas que decidem a escolha

1. Qual é o perfil da carga?

MySQL com InnoDB brilha em OLTP: muitas transações curtas, muita leitura por chave primária, alta concorrência. Se a sua carga é analítica pesada — janelas, CTEs recursivas monstruosas, agregações sobre bilhões de linhas — a conversa muda, e o comparativo com PostgreSQL é a leitura certa.

2. Qual é o volume e o crescimento?

O limite prático não é o tamanho da tabela, é o tamanho do working set — a parte dos dados que precisa caber na memória. Tem tabela de 2 TB rodando lisa e tabela de 40 GB agonizando. Os números reais estão em Tenho muitos dados, posso usar MySQL?.

3. Quanto custa ficar fora do ar?

Essa é a pergunta que ninguém faz antes e todo mundo faz durante o incidente. Defina RPO (quanto dado você aceita perder) e RTO (quanto tempo você aceita ficar parado) antes de escolher a topologia. Detalhei arquiteturas em MySQL em aplicações críticas.

Os quatro ajustes que resolvem 80% dos problemas

Sintoma	Causa mais comum	Onde olhar
Tudo lento em horário de pico	Buffer pool pequeno	innodb_buffer_pool_size (50–70% da RAM)
Uma tela específica trava	Índice faltando	EXPLAIN ANALYZE da query
Locks e timeouts	Transação longa segurando linha	performance_schema.data_locks
Réplica atrasada	Replicação single-thread	replica_parallel_workers

Para caçar o que está pesando de verdade, o sys schema entrega de bandeja:

-- As 10 consultas que mais consomem tempo total no servidor
SELECT query, exec_count, ROUND(total_latency/1e12, 2) AS total_seg,
       rows_sent_avg, rows_examined_avg
FROM sys.statement_analysis
ORDER BY total_latency DESC
LIMIT 10;

Repare em rows_examined_avg muito maior que rows_sent_avg: isso é o banco lendo o mundo para devolver um punhado de linhas. Quase sempre é índice ausente ou índice existente sendo ignorado por conversão de tipo na cláusula WHERE.

Quando eu não indicaria MySQL

• Geoespacial avançado ou dados científicos: PostgreSQL com PostGIS ganha longe.
• Data warehouse puro sobre dezenas de TB: use uma engine colunar (ClickHouse, BigQuery) e deixe o MySQL como fonte transacional.
• Modelo de dados genuinamente sem esquema e com alta variação: aí um documental faz mais sentido que forçar JSON em tudo.

Fora esses casos? MySQL entrega — e entrega barato. Ele roda a maior parte da web justamente porque é previsível quando bem configurado.

Por onde continuar

Escolha o artigo que responde a sua dúvida específica na lista lá de cima. Se você quer sair do "sei fazer SELECT" para "sei operar", o caminho estruturado está no livro Aprendendo MySQL: Prática, Teoria e Laboratórios — 292 páginas, 10 laboratórios guiados, máquina virtual pronta e 277 exercícios com gabarito. E se você prefere aprender ao vivo, dê uma olhada nos treinamentos.

---

Sobre o autor: Alexandre Almeida trabalha com bancos de dados há mais de 25 anos, foi instrutor oficial de MySQL e Oracle para mais de 1.000 alunos e é autor de Aprendendo MySQL. Todos os comandos deste artigo foram testados em MySQL 8.0 e 8.4 LTS.

Fontes: documentação oficial do MySQL 8.4 (Reference Manual, capítulos InnoDB e Replication) e notas de release das versões 8.0.x.