| Sintoma observado | Causa raiz | Ação corretiva |
|---|---|---|
| Site e wp-admin caem juntos | Senha ou usuário errado no wp-config.php | Conferir credenciais no painel do host |
| Erro intermitente em horário de pico | MySQL derrubado por falta de memória | Aumentar RAM ou limite de conexões |
| Front-end quebra, wp-admin sugere reparo | Tabela do banco corrompida | Ativar o modo de reparo do WordPress |
| Erro após migração de servidor | DB_HOST incorreto no wp-config.php | Ajustar o host para o valor do novo servidor |
Legenda: a mensagem ocupa a tela inteira porque o WordPress não consegue carregar nem o tema nem o painel sem o banco.
--- ## Causa 1: Credencial errada no wp-config.php A causa número 1 do erro de conexão com o banco de dados é uma credencial trocada no arquivo wp-config.php. As 4 constantes DB_NAME, DB_USER, DB_PASSWORD e DB_HOST guardam o nome do banco, o usuário, a senha e o endereço do servidor MySQL. Basta um caractere errado na senha para o MySQL recusar a conexão e o site cair por completo. O padrão causal é direto: a senha do banco trocada pelo host no painel mais o wp-config.php com a credencial antiga resulta em recusa imediata do MySQL. Isso é comum logo após uma redefinição de senha ou troca de plano. Para confirmar, abra o painel do seu host, vá em bancos de dados MySQL ou MariaDB e compare cada valor com o que está no wp-config.php. A gente vê esse cenário em sites que migraram de host e herdaram credenciais antigas. Veja o passo a passo de como editar o wp-config.php com segurança. --- ## Causa 2: O servidor MySQL caiu ou está sobrecarregado A segunda causa do erro de conexão com o banco de dados é o próprio servidor MySQL fora do ar. Mesmo com as credenciais certas, se o processo do banco travou ou foi derrubado por falta de memória, o WordPress recebe uma recusa e exibe a mesma tela. Em hospedagem compartilhada, 1 vizinho consumindo todos os recursos derruba o MySQL de vários sites de uma vez. A relação causal aparece sob carga: um pico de tráfego em VPS com limite baixo de max_connections mais o MySQL derrubado por falta de memória deixa o banco offline e o site fora do ar. Esse erro tende a ser intermitente: some quando a carga cai e volta no próximo pico. Para confirmar, rode um script PHP curto com mysqli_connect() usando as mesmas credenciais. Se conectar fora do WordPress, o problema é de carga, não de senha. Vale ler como corrigir o erro interno do servidor, que costuma andar junto. --- ## Causa 3: Uma tabela do banco de dados corrompeu Quando o front-end quebra mas o wp-admin sugere reparar o banco, a conexão com o banco de dados está viva, porém uma tabela corrompeu. Uma atualização interrompida, uma queda de energia no servidor ou um disco cheio podem deixar a tabela wp_options ou wp_posts em estado inconsistente, e o MySQL responde mas entrega dados quebrados. O padrão é específico: uma atualização interrompida ou queda de energia no servidor mais a tabela wp_options corrompida faz o MySQL responder, mas o WordPress não consegue ler as opções do site. A correção nativa é o modo de reparo: adicione a linha define('WP_ALLOW_REPAIR', true); ao wp-config.php e acesse seusite.com/wp-admin/maint/repair.php. O WordPress varre e conserta cada tabela sem plugin. Remova a linha depois, por segurança. Para casos mais sérios, o phpMyAdmin oferece a opção "Reparar tabela" direto na interface. Manter um backup do banco de dados recente é o que separa um susto de 5 minutos de uma perda real de conteúdo. --- ## Causa 4: O db_host está apontando para o lugar errado A quarta causa do erro de conexão com o banco de dados é um valor de DB_HOST incorreto, quase sempre após uma migração. Muitos hosts usam localhost, mas outros exigem um endereço específico como MySQL.seudominio.com ou um IP com porta. Se o wp-config.php traz localhost num servidor que espera outro host, a conexão com o banco de dados falha mesmo com usuário e senha corretos. A lógica é de ambiente: o DB_HOST com localhost num servidor que usa um host dedicado mais a tentativa de conexão resulta em "Unknown MySQL server host". O WordPress nem valida a senha, porque não encontra a máquina do banco. A correção é confiar no valor que o painel de hospedagem informa. Em ambientes gerenciados, esse dado fica na seção de bancos de dados; em servidores próprios, costuma ser 127.0.0.1 com a porta 3306. Trocar localhost pelo host correto resolve a maioria das migrações. --- ## Causa 5: O limite de conexões do banco estourou O erro de conexão com o banco de dados também aparece quando o número de conexões simultâneas ao MySQL ultrapassa o limite configurado. Cada visita ativa abre uma conexão, e plugins mal otimizados ou consultas lentas seguram essas conexões por mais tempo. Quando o limite max_connections do servidor estoura, o próximo visitante recebe "Too many connections" no lugar do site. A causa é de capacidade: muitas requisições simultâneas mais consultas lentas que não liberam a conexão esgotam o pool do MySQL e travam os acessos seguintes. Esse cenário cresce em lojas WooCommerce e sites com muitos plugins. A correção definitiva combina otimização e infraestrutura: limpe revisões e transients acumulados, ative cache de objeto com Redis e, se o padrão persistir, suba o limite de conexões ou a memória do servidor. Vale rodar uma rotina de otimização do banco de dados para reduzir o peso de cada consulta antes de pagar por mais hardware. --- ## Causa 6: O arquivo wp-config.php corrompeu ou está incompleto A sexta causa do erro de conexão com o banco de dados é um wp-config.php corrompido por edição malfeita. Um espaço antes da tag de abertura do PHP, uma aspa no lugar errado ou caracteres invisíveis colados de um editor de texto quebram a leitura das constantes do banco. O arquivo existe, mas o PHP não interpreta as credenciais. O padrão técnico é claro: o wp-config.php editado em um editor que insere BOM mais o PHP 8.2 interpretando o arquivo resulta em constantes do banco não definidas. O sintoma costuma ser a tela de erro com avisos de "headers already sent". A correção é reabrir o arquivo em um editor de código como o VS Code e conferir se ele começa exatamente com a tag do PHP, sem nada antes. Na dúvida, baixe um wp-config-sample.php limpo e reescreva as 4 constantes do zero. Siga as boas práticas de como evitar erros de configuração no WordPress. --- ## Padronize o ambiente e evite o próximo apagão A maioria dos casos do erro de conexão com o banco de dados se resolve conferindo as credenciais no wp-config.php e confirmando que o MySQL está de pé, sem tocar em código complexo. O problema é que ele tende a voltar quando o ambiente não está padronizado e cada deploy mexe na configuração. O plano PRO da FULL custa R$849 e cobre até 10 sites, o que dá cerca de R$85 por site, com os 17 plugins do bundle (incluindo WP Rocket, All in One Security e UpdraftPlus para backup) já configurados para conviver com o banco sem conflito. A gente cuida dessa camada chata de infraestrutura para você focar no conteúdo. Conheça os planos da FULL e blinde o ambiente antes do próximo apagão.Sim, em boa parte dos casos a conexão com o banco de dados volta sem mexer em código. O caminho mais rápido é conferir no painel do host se o serviço MySQL está ativo e se a senha do banco bate com a do wp-config.php. Se o servidor caiu por carga, reiniciar o MySQL pelo painel já resolve, sem tocar em arquivo nenhum.
Porque o wp-admin também depende do banco. Diferente de um erro de tema, que afeta só a parte visível, a conexão com o banco de dados é a base de tudo no WordPress. O painel precisa ler usuários, opções e permissões do MySQL para carregar. Sem banco, nem o login aparece. Por isso o erro derruba front-end e administração ao mesmo tempo.
Crie um arquivo PHP com mysqli_connect() usando as 4 credenciais do wp-config.php e abra no navegador. Se conectar, o MySQL está vivo e a falha é de carga ou tabela. Se recusar, a credencial ou o DB_HOST estão errados. Esse teste de 1 minuto separa problema de senha de problema de servidor antes de qualquer suposição.
Pode, e é uma causa frequente em VPS apertado. Cada visita abre uma conexão com o MySQL, e quando o limite max_connections estoura, o próximo acesso recebe "Too many connections". O erro fica intermitente, sumindo quando a carga cai. A correção combina cache de objeto com Redis e aumento do limite de conexões ou da memória do servidor.
Sim, desde que você remova a linha depois. Adicionar define('WP_ALLOW_REPAIR', true); ao wp-config.php libera a página repair.php, que conserta tabelas corrompidas do banco sem plugin. O risco é deixar essa linha ativa, porque a página fica acessível sem login. Use, repare a tabela e apague a constante na sequência para fechar a brecha.