Atualizado em 19/06/2026
Quando o WordPress exibe a mensagem "Erro ao estabelecer uma conexão com o banco de dados" (em inglês, Error establishing a database connection), o site inteiro para. Diferente de outros erros, esse não mostra layout nem conteúdo — só a frase em uma página simples. A causa está sempre na ponte entre o WordPress e o MySQL, e na maioria dos casos é totalmente reversível.
Antes de mexer no banco: nunca rode reparos, importações ou exclusões sem um backup recente do banco de dados. Uma tentativa de conserto sem cópia de segurança é a forma mais rápida de transformar uma falha de conexão em perda definitiva de conteúdo. Faça (ou peça) o backup primeiro.
O que essa mensagem significa
Todo o conteúdo do seu site — posts, páginas, produtos, comentários, usuários e configurações — vive em um banco de dados MySQL/MariaDB. O WordPress, a cada visita, precisa se conectar a esse banco usando as credenciais guardadas no arquivo wp-config.php. Quando essa conexão falha, ele não consegue buscar nada e exibe a mensagem de erro no lugar da página. Em resumo: o WordPress está de pé, mas não está conseguindo conversar com o banco.
As causas mais comuns
- Credenciais erradas no
wp-config.php:DB_NAME,DB_USER,DB_PASSWORDouDB_HOSTincorretos. É a causa nº 1, especialmente após migração de servidor, quando esses valores mudam. - Servidor MySQL fora do ar ou sobrecarregado: o serviço de banco da hospedagem caiu, está em manutenção ou não responde por excesso de carga.
- Banco ou tabelas corrompidos: uma queda durante uma gravação, um plugin problemático ou disco cheio podem corromper tabelas.
- Excesso de conexões: em hospedagem compartilhada, picos de acesso ou consultas pesadas estouram o limite de conexões simultâneas e a conexão é recusada.
- Site invadido: um site comprometido pode bombardear o banco com consultas, alterar credenciais ou corromper dados — ver WordPress hackeado.
Site x painel: uma pista importante
Observe a mensagem nos dois lugares. Se o site público e o /wp-admin mostram o mesmo erro de conexão, o problema é de acesso ao banco — credenciais ou servidor MySQL. Mas se o site mostra o erro genérico e o painel exibe "One or more database tables are unavailable. The database may need to be repaired", a conexão até funciona: o que está ruim são as tabelas corrompidas. Essa diferença muda completamente o que precisa ser feito.
Por que a distinção importa: credenciais erradas se resolvem corrigindo o wp-config.php; tabelas corrompidas, com reparo do banco. Tentar reparar tabelas quando o problema é só de credencial não adianta — e mexer às cegas no banco sem necessidade só aumenta o risco.
O que você pode verificar
- Confira as credenciais: abra o
wp-config.phpe verifiqueDB_NAME,DB_USER,DB_PASSWORDeDB_HOSTcontra os dados reais do banco no painel da hospedagem. - Confirme o
DB_HOST: em muitas hospedagens não élocalhost, e sim um endereço específico do servidor de banco. Esse é um tropeço clássico após migração. - Teste o banco direto: entre no painel da hospedagem ou no phpMyAdmin e veja se consegue acessar o banco com aquele usuário e senha. Se nem por ali entra, o problema é a credencial ou o servidor.
- Verifique se o MySQL está no ar: cheque o status dos serviços no painel e procure avisos de manutenção ou indisponibilidade da hospedagem.
- Repare o banco (com cuidado): se o painel acusa tabelas indisponíveis, adicione
define('WP_ALLOW_REPAIR', true);aowp-config.php, acesse/wp-admin/maint/repair.php, rode o reparo e remova a linha depois. - Fale com a hospedagem: pergunte sobre limites de conexão, carga do servidor de banco e eventuais bloqueios — em planos compartilhados, esse é um gargalo frequente.
As credenciais no wp-config.php
As quatro constantes abaixo são o ponto exato onde o WordPress guarda como falar com o MySQL. Confira cada uma contra os dados reais do painel da hospedagem — um caractere errado já derruba a conexão:
// Credenciais de conexao com o banco (wp-config.php)
define('DB_NAME', 'nome_do_banco');
define('DB_USER', 'usuario_do_banco');
define('DB_PASSWORD', 'senha_do_banco');
define('DB_HOST', 'localhost'); // veja a tabela abaixo
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');Atenção a detalhes silenciosos: senhas com aspas ou caracteres especiais precisam ser idênticas (copie e cole do painel), e em algumas hospedagens o nome do banco e do usuário vêm com um prefixo (por exemplo conta123_wp). Depois de migrar de servidor, é quase sempre aqui que mora o erro.
Quando o problema é a tabela, não a credencial
Se o painel acusa "tables are unavailable… may need to be repaired", a conexão funciona — o que está corrompido são as tabelas. O WordPress traz um reparo embutido. Acrescente ao wp-config.php, acima de /* That's all, stop editing! */:
define('WP_ALLOW_REPAIR', true);Em seguida acesse seusite.com.br/wp-admin/maint/repair.php (sem precisar de login), clique em Repair Database e, terminado, remova a linha — ela deixa a página aberta a qualquer um. Faça o backup do banco antes de reparar.
Valor de DB_HOST | Como conecta | Quando usar |
|---|---|---|
localhost | Socket Unix local. | Padrão na maioria das hospedagens compartilhadas, com banco no mesmo servidor. |
127.0.0.1 | TCP/IP pela porta 3306, mesma máquina. | Quando localhost falha ou o ambiente não usa socket (containers, alguns painéis). |
host remoto (ex.: mysql.seudominio.com.br) | TCP/IP para outro servidor. | Hospedagem gerenciada ou banco em servidor separado; use o host exato do painel. |
host:porta (ex.: 10.0.0.5:3307) | TCP/IP em porta não padrão. | Quando o MySQL escuta numa porta diferente da 3306. |
localhost:/caminho/mysql.sock | Socket Unix em caminho explícito. | Servidores que não usam o socket padrão; o caminho vem da hospedagem. |
Editar o wp-config.php e usar o phpMyAdmin exige acesso por FTP/SFTP e ao painel da hospedagem. Se você não tem esses acessos ou não se sente confortável manuseando credenciais de banco, é melhor não arriscar — um erro de digitação aqui mantém o site fora do ar.
Como eu resolvo
Com acesso à hospedagem e ao FTP, sigo um roteiro seguro:
- Faço backup do banco de dados (e dos arquivos) antes de qualquer reparo ou alteração.
- Confirmo as credenciais no
wp-config.phpcontra o painel e ajustoDB_NAME,DB_USER,DB_PASSWORDeDB_HOST— o passo decisivo após migrações. - Testo a conexão pelo phpMyAdmin e verifico se o serviço MySQL está saudável.
- Quando há corrupção, rodo o reparo do banco com segurança e removo a permissão de reparo em seguida.
- Em problemas de limite/sobrecarga, converso com a hospedagem e otimizo consultas e plugins que pesam no banco.
- Se houver sinal de invasão, trato a segurança junto, para o erro não voltar.
Dica que vale ouro: a maior parte do estrago em problemas de banco acontece por falta de backup na hora certa. Mantenha um backup automático do WordPress (arquivos + banco) e qualquer falha de conexão deixa de ser pânico e vira só um ajuste.
Perguntas frequentes
O que significa "Erro ao estabelecer uma conexão com o banco de dados"?
Significa que o WordPress até carregou, mas não conseguiu falar com o banco de dados MySQL onde ficam seus posts, páginas, usuários e configurações. Sem essa conexão, ele não tem como montar nenhuma página. A mensagem em inglês equivalente é "Error establishing a database connection".
Apareceu logo depois de migrar de servidor. Por quê?
É a causa mais comum nesse cenário: no servidor novo, o nome do banco, o usuário, a senha ou o DB_HOST mudaram, mas o wp-config.php ainda aponta para os dados antigos. Basta corrigir essas quatro credenciais no wp-config.php com os valores do novo servidor para o site voltar.
O site mostra o erro, mas o /wp-admin diz outra coisa. Isso ajuda?
Ajuda bastante. Quando o painel exibe "One or more database tables are unavailable. The database may need to be repaired", o problema não é a conexão e sim tabelas corrompidas. Isso aponta para reparo do banco, não para credenciais erradas — são caminhos diferentes.
Como reparo o banco de dados do WordPress?
O WordPress tem um reparo embutido: adicione define('WP_ALLOW_REPAIR', true); ao wp-config.php e acesse seusite.com.br/wp-admin/maint/repair.php. Rode o reparo e, depois, remova essa linha do arquivo — deixá-la ativa é um risco de segurança.
Esse erro pode ser sinal de invasão?
Pode. Um site comprometido às vezes recebe conexões e consultas demais ao banco, esgotando os limites e derrubando a conexão; em outros casos, o invasor altera credenciais ou corrompe tabelas. Se o erro vier acompanhado de comportamento estranho, vale tratar como possível WordPress hackeado.
Vou perder meu conteúdo por causa desse erro?
Na maioria dos casos, não — é um problema de acesso ao banco, não de exclusão de dados. O risco real aparece quando há corrupção sem backup. Por isso eu sempre faço um backup do banco antes de qualquer reparo. Me chame no WhatsApp (43) 99932-9697 que eu avalio com segurança.
Qual valor devo usar em DB_HOST: localhost ou 127.0.0.1?
Depende de como a hospedagem expõe o MySQL. localhost faz o PHP conectar por um socket Unix local; 127.0.0.1 força conexão TCP pela porta 3306. Em muitos servidores compartilhados os dois funcionam, mas há casos em que só um deles conecta — se localhost dá erro, vale testar 127.0.0.1 e vice-versa. Em hospedagem gerenciada, o DB_HOST costuma ser um host remoto específico (algo como mysql.seudominio.com.br), informado no painel.
Adicionei WP_ALLOW_REPAIR e agora qualquer um acessa a página de reparo?
Sim — e por isso é uma medida temporária. Enquanto define('WP_ALLOW_REPAIR', true); estiver no wp-config.php, a página /wp-admin/maint/repair.php fica acessível sem login. Rode o reparo, confirme que o site voltou e remova a linha imediatamente. Deixá-la ativa é uma brecha que pode ser explorada — trate como questão de segurança, no mesmo nível de um site comprometido.