Toda vez que preciso migrar um banco de dados de um servidor pra outro, tem alguém no chat perguntando “por que não faz pelo phpMyAdmin mesmo?”. Resposta curta: porque phpMyAdmin trava ou dá timeout em qualquer dump acima de uns 50-100MB, e boa parte dos bancos de produção que mexo passam disso fácil. Linha de comando não trava, é mais rápido, e dá controle fino sobre o que está acontecendo — mas tem umas pegadinhas que travam quem está fazendo pela primeira vez.
Antes de importar: crie o banco de destino
O comando de importação não cria o banco de dados sozinho — ele espera que o banco já exista e esteja vazio (ou pelo menos que as tabelas não tenham conflito). Faça isso primeiro:
mysql -u root -p -e "CREATE DATABASE nome_do_banco CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"Reparar o charset depois de importar com o banco errado é bem mais chato do que definir certo desde o início — principalmente se o dump tem acentuação ou emoji em algum campo de texto.
Importando o dump via linha de comando
- Se o dump está em um arquivo .sql simples:
mysql -u root -p nome_do_banco < caminho/para/arquivo.sql - Se o dump está compactado em .sql.gz (comum em backups grandes, pra economizar espaço em trânsito):
gunzip < arquivo.sql.gz | mysql -u root -p nome_do_banco - Para acompanhar o progresso em dumps grandes (o comando padrão não mostra nada até terminar, o que assusta quem não sabe), instale o
pve use:pv arquivo.sql | mysql -u root -p nome_do_banco
Ajustes que evitam erro no meio da importação
Em bancos grandes ou com muitas foreign keys, é comum a importação parar no meio com erro de timeout ou de restrição de chave estrangeira. Antes de rodar, ajuste temporariamente:
SET GLOBAL max_allowed_packet=1073741824;
SET GLOBAL net_read_timeout=600;
SET GLOBAL net_write_timeout=600;Esses valores voltam ao padrão depois de reiniciar o MySQL, então não precisa se preocupar em desfazer manualmente. O max_allowed_packet em particular é o vilão mais comum quando o dump tem alguma linha muito grande (campo BLOB ou texto longo), e o erro que aparece ("MySQL server has gone away") não deixa óbvio que é isso.
Problemas comuns e como resolver
1. Erro "Access denied" mesmo com senha certa. Geralmente é permissão do usuário no banco específico, não senha errada. Confirme com SHOW GRANTS FOR 'usuario'@'localhost'; e, se precisar, libere acesso: GRANT ALL PRIVILEGES ON nome_do_banco.* TO 'usuario'@'localhost'; seguido de FLUSH PRIVILEGES;.
2. Importação "termina" rápido demais e o banco fica incompleto. Quase sempre é erro no meio do processo que o terminal engoliu silenciosamente. Rode de novo redirecionando os erros para um arquivo: mysql -u root -p nome_do_banco < arquivo.sql 2> erros.log e leia o log — o erro real geralmente está logo no início do arquivo, não no fim.
3. Caracteres acentuados viram símbolos estranhos depois de importar. É praticamente sempre charset incompatível entre o dump original e o banco de destino. Confirme o charset usado no dump original (normalmente vem comentado no topo do arquivo .sql) e recrie o banco de destino com o mesmo charset antes de importar de novo — não dá para simplesmente converter depois sem risco de corromper acentuação.
Perguntas frequentes
Dá pra importar direto de um servidor remoto sem baixar o arquivo primeiro? Sim, com mysqldump direto no pipe: mysqldump -h servidor_origem -u usuario -p banco | mysql -u usuario -p banco_destino, mas isso deixa a conexão vulnerável durante a transferência — melhor usar túnel SSH em produção.
Como sei se a importação terminou com sucesso? O terminal volta ao prompt sem mensagem de erro. Para confirmar de verdade, rode SHOW TABLES; no banco de destino e compare a contagem de linhas de uma tabela grande com a origem.
Qual o tamanho máximo de dump que dá pra importar assim? Não há limite prático da linha de comando em si — já importei dumps de 40GB+ dessa forma. O limite real costuma ser espaço em disco e tempo disponível, não a ferramenta.
Se seu fluxo de trabalho já inclui rodar MySQL localmente com XAMPP, vale revisar esse guia de configuração, e antes de qualquer migração importante, sempre gere um backup completo seguindo este passo a passo de backup MySQL — migração dando errado sem backup recente é a receita clássica pra um dia ruim.
Gerando o dump certo do lado da origem também evita dor de cabeça
Metade dos problemas de importação, na verdade, nasce na hora de gerar o dump, não na hora de importar. Um mysqldump básico sem as flags certas pode gerar um arquivo que trava exatamente nos pontos citados acima. As flags que mais evitam retrabalho:
mysqldump -u root -p --single-transaction --routines --triggers --events nome_do_banco > dump.sql--single-transaction garante um snapshot consistente sem travar as tabelas durante o dump (essencial em banco de produção rodando ao vivo). --routines, --triggers e --events incluem procedures, triggers e eventos agendados, que muita gente esquece e só percebe a falta quando alguma automação para de funcionar depois da migração.
Para bancos muito grandes, vale dividir o dump por tabela em vez de gerar um arquivo monolítico — facilita tanto para acompanhar progresso quanto para reimportar só a tabela que deu problema, sem repetir tudo do zero:
mysqldump -u root -p nome_do_banco tabela_especifica > tabela_especifica.sqlIsso também ajuda muito na hora de debugar: se a importação falha, você sabe exatamente em qual tabela parar de procurar, em vez de vasculhar um arquivo de vários gigabytes atrás de uma linha quebrada.
Um detalhe que só quem já apanhou nisso sabe: se o dump de origem foi gerado numa versão de MySQL mais nova que o destino, comandos ou tipos de dados específicos daquela versão podem quebrar a importação com um erro de sintaxe que não tem nada a ver com o que parece à primeira vista. Sempre confira a versão do MySQL/MariaDB dos dois lados antes de perder tempo depurando outra coisa.
