Se o XAMPP mostra Error: MySQL shutdown unexpectedly em vermelho, o serviço tentou iniciar e falhou. Na maioria dos casos a causa é uma só: arquivos do banco corrompidos por um desligamento abrupto — o computador que travou, a queda de energia, ou o XAMPP fechado sem parar o MySQL antes. As outras causas frequentes são a porta 3306 ocupada por outro programa e a falta do Visual C++ Redistributable no Windows.
Antes de seguir qualquer tutorial, um aviso que vale mais que todos os passos: faça uma cópia da pasta xampp/mysql/data agora, antes de mexer em qualquer coisa. A maior parte das soluções que circulam pede para apagar ou renomear arquivos dessa pasta — e é onde estão os seus bancos.
Antes de tudo: copie a pasta xampp/mysql/data para outro lugar. Depois abra o log em xampp/mysql/data/mysql_error.log — ele diz a causa exata.
| Aconteceu depois de um travamento | Arquivos InnoDB corrompidos — a causa nº 1 |
Log fala em porta ou bind | Outro programa ocupa a 3306 |
| Instalou o XAMPP agora | Falta o Visual C++ Redistributable |
Log fala em permission ou access denied | Rode o XAMPP como administrador |
Conteúdo
O que a mensagem significa
O painel do XAMPP exibe algo assim:
Error: MySQL shutdown unexpectedly.
This may be due to a blocked port, missing dependencies,
improper privileges, a crash, or a shutdown by another method.
A própria mensagem lista cinco possibilidades — porta bloqueada, dependências faltando, permissões, travamento, ou desligamento por outro meio. É uma mensagem genérica: o XAMPP percebeu que o processo morreu, mas não sabe por quê.
Quem sabe é o log. E é justamente ele que a maioria dos tutoriais pula.
Um detalhe que confunde: as versões atuais do XAMPP não incluem MySQL, e sim MariaDB — o fork criado pelos desenvolvedores originais. O painel continua chamando de “MySQL” por compatibilidade, mas o que roda ali é MariaDB. Na prática, o comportamento e as soluções são os mesmos. Nosso guia sobre o que é MySQL explica a diferença entre os dois.
Antes de qualquer correção: copie a pasta data
Este passo não é opcional, e é o motivo de tanta gente perder o trabalho de meses.
Vá até C:\xampp\mysql\ e copie a pasta data inteira para a área de trabalho, um pendrive, ou qualquer lugar fora do XAMPP. Dentro dela estão todos os seus bancos.
Boa parte das soluções que você vai encontrar — inclusive as deste artigo — envolve renomear, substituir ou apagar arquivos dessa pasta. Se algo der errado no processo e você não tiver a cópia, não há como voltar atrás.
Existe uma pasta xampp/mysql/backup, e vários tutoriais mandam copiá-la para data como solução. Funciona para fazer o MySQL iniciar — mas entenda o que ela é: uma cópia das tabelas de sistema do momento da instalação, não dos seus dados. Restaurá-la faz o serviço subir com os bancos vazios. Os seus bancos continuam na pasta antiga, e precisam ser recuperados de lá num segundo passo.
Passo 1: leia o log de erro
É o que separa uma correção de dez minutos de uma tarde inteira tentando soluções aleatórias.
Pelo painel do XAMPP: clique no botão Logs na linha do MySQL e escolha mysql_error.log.
Pelo Explorador de Arquivos: abra C:\xampp\mysql\data\mysql_error.log no Bloco de Notas.
Role até o fim do arquivo — as últimas linhas são da tentativa mais recente. O que você encontrar ali diz o que fazer.
| O que aparece no log | Causa |
|---|---|
InnoDB: Database page corruptionInnoDB: Assertion failure | Arquivos InnoDB corrompidos — desligamento abrupto |
Can't start server: Bind on TCP/IP portAddress already in use | Porta 3306 ocupada por outro programa |
Can't create/write to filePermission denied | Permissões — rode como administrador |
Table 'mysql.user' doesn't exist | Tabelas de sistema faltando ou corrompidas |
InnoDB: Operating system error number 32 | Arquivo travado por outro processo ou antivírus |
| O log está vazio ou não existe | O processo nem chegou a iniciar — provavelmente falta o Visual C++ |
Causa 1: arquivos InnoDB corrompidos
A mais comum, e a que quase sempre aparece depois de um travamento do Windows, uma queda de energia, ou de fechar o XAMPP sem parar o MySQL antes.
O InnoDB — o motor de armazenamento padrão — guarda o dicionário de dados num arquivo chamado ibdata1 e os logs de transação em ib_logfile0 e ib_logfile1. Se o processo é interrompido no meio de uma escrita, esses arquivos ficam inconsistentes e o serviço se recusa a subir.
O procedimento, na ordem:
- Confirme que você copiou a pasta
datapara fora do XAMPP - Renomeie
xampp/mysql/dataparadata_old - Crie uma pasta nova chamada
data - Copie todo o conteúdo de
xampp/mysql/backuppara dentro da novadata - De
data_old, copie as pastas dos seus bancos (cada banco é uma pasta com o nome dele) para a novadata— mas não copie as pastasmysql,performance_schemaephpmyadmin - De
data_old, copie também o arquivoibdata1para a novadata - Inicie o MySQL pelo painel
O ibdata1 guarda o dicionário das tabelas InnoDB — a lista do que existe e onde está. Os dados em si ficam nos arquivos .ibd dentro das pastas de cada banco. Os dois precisam ser da mesma origem: se você copiar o ibdata1 antigo e esquecer os .ibd, ou o contrário, o InnoDB encontra uma referência para algo que não existe e falha.
E se o ibdata1 for justamente o arquivo corrompido, copiá-lo reproduz o problema na pasta nova. Nesse caso, o serviço sobe sem ele — mas os bancos InnoDB ficam inacessíveis, e a recuperação exige um caminho diferente, descrito mais abaixo.
Se o serviço subir, confira imediatamente se os seus bancos aparecem no phpMyAdmin. Não basta o MySQL iniciar: é preciso que os dados estejam lá.
Causa 2: a porta 3306 está ocupada
O MySQL não consegue iniciar se outro programa já está escutando na porta dele. Os suspeitos habituais são um MySQL instalado separadamente (fora do XAMPP), o WAMP, o Laragon, ou uma instância antiga que não encerrou.
Como confirmar, no Prompt de Comando:
netstat -ano | findstr :3306
Se aparecer alguma linha, a porta está ocupada — e o último número é o PID do processo. Você identifica quem é no Gerenciador de Tarefas, na aba Detalhes.
Duas saídas:
Encerrar o outro programa. Se for um serviço do Windows, abra services.msc, procure por MySQL ou MariaDB, e pare o serviço. Se for outro ambiente local, feche-o.
Ou mudar a porta do XAMPP. No painel, clique em Config na linha do MySQL e abra o my.ini. Troque as duas ocorrências de port=3306 para port=3307, salve e reinicie.
Se mudar a porta, lembre que as aplicações precisam saber disso — no WordPress, o DB_HOST passa a ser localhost:3307. Nosso guia sobre a porta 3306 explica o funcionamento e como testar.
Causa 3: falta o Visual C++ Redistributable
Causa frequente em instalação nova do XAMPP no Windows, e praticamente invisível: o log fica vazio, porque o processo nem chega a iniciar.
O MySQL do XAMPP depende das bibliotecas do Microsoft Visual C++ Redistributable. Sem elas, ele falha silenciosamente.
Como verificar: abra Painel de Controle → Programas e Recursos e procure por “Microsoft Visual C++ 2015-2022 Redistributable (x64)”. Se não estiver na lista, baixe do site oficial da Microsoft, instale, reinicie o computador e tente novamente.
Causa 4: permissões insuficientes
Se o log menciona Permission denied ou Can't create/write to file, o XAMPP não tem permissão para escrever na própria pasta.
Primeiro teste: feche o XAMPP, clique com o botão direito no atalho e escolha Executar como administrador.
Se resolver, vale tornar permanente: botão direito no xampp-control.exe → Propriedades → Compatibilidade → marcar Executar este programa como administrador.
Uma causa relacionada: o XAMPP instalado em C:\Program Files costuma dar esse problema, porque o Windows protege essa pasta. A instalação recomendada é direto em C:\xampp.
Causa 5: antivírus ou outro processo travando arquivos
Se o log traz Operating system error number 32 — “arquivo em uso por outro processo” —, algo está segurando os arquivos do banco.
Antivírus é o suspeito mais comum: alguns fazem varredura em tempo real dentro da pasta data e travam o ibdata1 no momento em que o MySQL tenta abri-lo. A solução é adicionar C:\xampp à lista de exclusões do antivírus.
Um processo mysqld.exe órfão também causa isso. Abra o Gerenciador de Tarefas, procure por mysqld.exe na aba Detalhes, e finalize o processo antes de tentar de novo.
Causa 6: disco cheio
Simples e frequentemente esquecida: o MySQL precisa de espaço para os logs de transação, e se o disco está cheio ele não inicia.
Verifique o espaço livre na unidade onde o XAMPP está instalado. Menos de 1 GB já é motivo de preocupação.
Como recuperar seus bancos quando nada funciona
Se o serviço subiu mas os bancos não aparecem, ou se o ibdata1 estava corrompido, a recuperação depende do motor de armazenamento das tabelas.
Tabelas MyISAM são autocontidas: cada uma tem três arquivos — .frm, .MYD e .MYI — dentro da pasta do banco. Copiá-los para a instalação nova costuma funcionar, mesmo sem o ibdata1 original.
Tabelas InnoDB não são. Os dados ficam em arquivos .ibd, mas a estrutura que diz como lê-los está no ibdata1. Sem o ibdata1 correspondente, os .ibd sozinhos não são recuperáveis pelos meios normais.
Um último recurso é iniciar o MySQL em modo de recuperação. No my.ini, na seção [mysqld], acrescente:
innodb_force_recovery = 1
Salve e tente iniciar. Se não subir, aumente o número gradualmente até 6 — mas saiba que a partir do nível 4 o processo pode causar perda de dados. Assim que o serviço subir, exporte tudo imediatamente pelo phpMyAdmin, remova a linha do my.ini, e reinstale o XAMPP do zero para importar os dados de volta.
Ao exportar, atenção ao charset: nosso guia sobre acentuação quebrada no MySQL mostra como não perder os acentos no processo.
Como evitar que aconteça de novo
Quase todos os casos vêm do mesmo comportamento — e a prevenção é simples:
Pare o MySQL antes de desligar o computador. No painel do XAMPP, clique em Stop na linha do MySQL e espere o indicador apagar. Fechar o painel ou desligar a máquina com o serviço rodando é o que corrompe os arquivos.
Faça backup dos bancos regularmente. Exportar pelo phpMyAdmin leva segundos e é a única garantia real — nosso guia sobre backup pelo phpMyAdmin mostra o processo.
Exclua a pasta do XAMPP do antivírus, para evitar travamento de arquivos.
Não instale o XAMPP em C:\Program Files.
O XAMPP é ótimo para estudar, mas só funciona com o seu computador ligado — e o banco corrompe quando ele desliga errado. Na Homehost, o MySQL já vem rodando, com phpMyAdmin no painel, backup automático e servidor no Brasil. A partir de R$ 7,90/mês.
Ver planos de hospedagemPerguntas frequentes
O que significa “Error: MySQL shutdown unexpectedly”?
Significa que o XAMPP tentou iniciar o serviço do MySQL e o processo terminou antes de ficar pronto. É uma mensagem genérica — a causa exata está no arquivo mysql_error.log, dentro de xampp/mysql/data. As causas mais comuns são arquivos corrompidos por desligamento abrupto, porta 3306 ocupada e falta do Visual C++ Redistributable.
Vou perder meus bancos de dados?
Não necessariamente, e o mais importante é agir com calma: copie a pasta xampp/mysql/data para outro lugar antes de tentar qualquer correção. Os seus bancos estão ali. A maioria das soluções envolve renomear ou substituir arquivos dessa pasta, e sem a cópia não há como voltar atrás.
Posso apagar a pasta data para resolver?
Não apague — renomeie. Renomear para data_old produz o mesmo efeito de “começar do zero”, mas preserva os seus bancos para recuperação depois. Apagar é definitivo.
A pasta backup do XAMPP restaura meus dados?
Não. A pasta xampp/mysql/backup contém apenas as tabelas de sistema do momento da instalação — ela faz o serviço iniciar, mas com os bancos vazios. Seus dados continuam na pasta data antiga e precisam ser copiados de lá separadamente.
Por que o erro aconteceu do nada?
Quase sempre porque o MySQL não foi encerrado corretamente na última vez: o computador travou, faltou energia, ou o XAMPP foi fechado com o serviço rodando. O InnoDB interrompido no meio de uma escrita deixa os arquivos inconsistentes, e na próxima inicialização o serviço se recusa a subir.
Como sei se a porta 3306 está ocupada?
No Prompt de Comando, rode netstat -ano | findstr :3306. Se aparecer alguma linha, há um processo usando a porta — o último número é o PID, que você identifica no Gerenciador de Tarefas. Os culpados mais comuns são um MySQL instalado separadamente, o WAMP ou o Laragon.
O que é o arquivo ibdata1?
É onde o InnoDB guarda o dicionário de dados — a estrutura que diz quais tabelas existem e como lê-las. Os dados em si ficam nos arquivos .ibd. Os dois precisam ser da mesma origem: copiar um sem o outro faz o InnoDB falhar, porque encontra referências para algo que não existe.
O XAMPP usa MySQL ou MariaDB?
As versões atuais incluem MariaDB, o fork criado pelos desenvolvedores originais do MySQL depois da compra pela Oracle. O painel continua exibindo “MySQL” por compatibilidade. Na prática, os comandos, o phpMyAdmin e as soluções para este erro são os mesmos.
Devo usar innodb_force_recovery?
Só como último recurso, e com cuidado. Comece no nível 1 e aumente gradualmente — a partir do nível 4, o processo pode causar perda de dados. Assim que o serviço subir, exporte tudo imediatamente, remova a linha do my.ini e reinstale o XAMPP para importar os dados de volta.
Veja também
Para entender o funcionamento do banco, veja o que é MySQL e o que é um banco de dados. Sobre o ambiente local e como publicar o projeto, veja o que é PHP. E se o erro for no site em produção e não no XAMPP, veja erro ao estabelecer uma conexão com o banco de dados.
Conclusão
A mensagem parece grave, mas raramente é: o serviço morreu, e o log diz por quê. O erro de quase todo mundo é seguir direto para o tutorial que manda apagar a pasta data — e é aí que os bancos se perdem, não no travamento original. Copie a pasta antes de qualquer coisa, leia as últimas linhas do mysql_error.log, e trate a causa que ele apontar. E, para não repetir: pare o MySQL pelo painel antes de desligar o computador. É esse gesto de dois segundos que evita a maior parte dos casos.
