7 sinais de aviso do banco de dados do WordPress que a maioria dos proprietários de sites ignora
John Turner
John Turner
Seu site está carregando. Visitantes não estão reclamando. Nada no wp-admin está gerando erros.
Ainda assim, seu banco de dados tem acumulado silenciosamente peso morto por meses, talvez anos.
O inchaço do banco de dados nem sempre aparece no front-end. Suas páginas podem parecer as mesmas para os visitantes, quer seu banco de dados esteja enxuto ou carregando milhares de revisões de posts.
Os problemas surgem em outro lugar: um backup que leva o dobro do tempo para ser concluído, uma migração que para no meio do caminho ou um painel administrativo que parece lento a cada carregamento de página.
Eu já vi isso em sites que, de outra forma, eram bem mantidos. Ninguém olhava o banco de dados há anos, e isso ficou evidente no momento em que tentamos migrar.
Esses sinais são específicos e diagnosticáveis. Você não precisa executar consultas SQL ou vasculhar o phpMyAdmin para saber se seu banco de dados precisa de atenção. Você só precisa saber o que procurar.
Mostrarei os principais sinais de que seu banco de dados WordPress precisa de otimização e como é um banco de dados saudável, para que você tenha um alvo a atingir.
Aqui estão os principais pontos:
- O inchaço do banco de dados pode ser invisível no front-end, especialmente em páginas em cache. Os sinais geralmente aparecem nos tamanhos de backup, tempos de migração e velocidade do admin, em vez de no seu site ativo.
- Os sinais a serem observados: admin lento, erros ao salvar posts, atrasos de "aguardando banco de dados" em testes de velocidade, carregamento lento de páginas não em cache, backups grandes demais, migrações lentas e tamanho desproporcional do banco de dados.
- Dados autoloaded acima de aproximadamente 800KB a 1MB podem se tornar uma preocupação, dependendo do site e da configuração de cache. A tabela wp_options é o primeiro lugar a verificar.
- Tabelas órfãs de plugins desinstalados se acumulam silenciosamente e contribuem para o tamanho do banco de dados sem adicionar nada útil.
- DB Optimizer dá ao seu banco de dados uma pontuação de saúde de 0 a 100 em cinco categorias, para que você saiba exatamente o que precisa de atenção antes de migrar ou fazer backup.
- Limpe antes de migrar, não depois. Um banco de dados menor significa um backup menor, uma transferência mais rápida e menos para depurar se algo der errado.
Sumário
- O que se Acumula no Seu Banco de Dados WordPress?
- 7 Sinais de que Seu Banco de Dados WordPress Precisa de Otimização
- Seu Admin do WordPress Está Notavelmente Lento
- Você Está Recebendo Erros ao Salvar Posts
- Ferramentas de Teste de Velocidade Mostram Atrasos de "Aguardando Banco de Dados"
- O Carregamento de Páginas é Lento em Solicitações Não em Cache
- Seus Backups São Maiores do que Deveriam Ser
- Migrações Levam Mais Tempo do que o Esperado
- Seu Banco de Dados Tem Tabelas Órfãs ou Tamanho Desproporcional
- Como é um Banco de Dados Saudável
- Como Verificar a Saúde do Seu Banco de Dados Antes da Sua Próxima Migração
- Perguntas Frequentes (FAQs)
O que se Acumula no Seu Banco de Dados WordPress?
O WordPress gera uma quantidade surpreendente de dados que não têm nada a ver com seu conteúdo real. Isso não é culpa sua; é apenas como a plataforma funciona.
Revisões de Posts
Toda vez que você salva ou atualiza um post, o WordPress armazena uma revisão dele. Não há um limite padrão embutido, a menos que você defina um.
Um post que você editou 50 vezes tem 50 cópias armazenadas em seu banco de dados. Em um blog ativo ou em um site onde vários editores estão trabalhando, essas cópias se acumulam rapidamente.
Transientes Expirados e Dados Autoloaded
Transients são registros temporários que os plugins armazenam em seu banco de dados. Coisas como respostas de API, resultados de consulta em cache e configurações de curta duração.
Eles são projetados para expirar por conta própria após um período definido. Frequentemente, eles permanecem no banco de dados até serem limpos ou acessados novamente.
Transients expirados podem se acumular em sua tabela wp_options, que é onde o WordPress armazena as configurações de todo o site. Aqueles marcados como "autoloaded" são carregados em cada solicitação de página não em cache.
Quando os dados "autoloaded" atingem a faixa de 800KB a 1MB ou mais, isso pode se tornar uma preocupação de desempenho. Isso adiciona sobrecarga a cada carregamento de página em seu site, seja no admin ou em outro lugar.
Comentários de Spam, Lixeira e Metadados Órfãos
Colocar um post na lixeira ou marcar um comentário como spam não o remove do banco de dados. Ele fica lá até que você o exclua permanentemente.
Plugins desativados deixam linhas em wp_postmeta e wp_options. Uma vez que um plugin é removido, essas linhas não têm registro pai ao qual se anexar.
Eles são chamados de metadados órfãos e se acumulam silenciosamente toda vez que você troca um plugin.
Sobrecarga de Tabela
Quando linhas são excluídas de uma tabela de banco de dados, o MySQL não recupera automaticamente esse espaço. As lacunas deixadas para trás são chamadas de sobrecarga.
Tabelas que lidam com escritas frequentes (como wp_options e wp_postmeta) podem acumular sobrecarga mais rapidamente do que outras. A sobrecarga geralmente não quebra nada, mas desperdiça espaço em disco e pode tornar algumas tarefas de manutenção menos eficientes.
7 Sinais de que Seu Banco de Dados WordPress Precisa de Otimização
Um site lento é fácil de culpar na hospedagem ou nos plugins. Esses sinais são mais específicos do que isso. Cada um aponta diretamente para o banco de dados.
- Admin lento do WordPress: O painel ignora o cache de página e consulta o banco de dados a cada carregamento. Uma tabela wp_options inchada torna cada página do admin lenta.
- Erros ao salvar posts: Falhas de gravação e corrupção de tabela produzem erros de salvamento que parecem conflitos de plugin, mas remontam ao banco de dados.
- "Aguardando banco de dados" em testes de velocidade: O GTmetrix identifica isso especificamente. Alto TTFB com resposta lenta do servidor aponta para tabelas fragmentadas, não para seu host.
- Carregamentos lentos de páginas não em cache: Usuários logados, editores e páginas de checkout do WooCommerce ignoram o cache. Se esses fluxos são lentos, o banco de dados é provavelmente o motivo.
- Backups excessivamente grandes: O tamanho do backup reflete diretamente o tamanho do banco de dados. O peso morto é copiado junto com todo o resto.
- Migrações lentas: Um banco de dados inchado produz um pacote de migração maior, um upload mais lento e mais coisas que podem dar errado durante a transferência.
- Tamanho desproporcional do banco de dados: Se o seu banco de dados for muito maior do que o número de conteúdo sugere, tabelas órfãs e lixo acumulado explicam a diferença.
Seu Admin do WordPress Está Notavelmente Lento
Esta é geralmente a primeira coisa que os proprietários de sites notam. O front-end parece bom, mas o painel, a lista de posts e a biblioteca de mídia carregam lentamente.
O admin do WordPress ignora completamente o cache de página. Cada página do admin depende de consultas ao banco de dados.
Quando wp_options fica inchado com transientes expirados e configurações de plugin remanescentes, o WordPress tem mais dados para processar em cada solicitação não armazenada em cache.
Eu já vi isso em sites onde os dados autoloaded cresceram além de 2 MB. Cada página do wp-admin levava vários segundos para responder.
A solução não foi um upgrade de hospedagem. Foi limpar o banco de dados.
Você está recebendo erros ao salvar posts
Erros intermitentes ao salvar posts são fáceis de culpar em um conflito de plugin. O banco de dados é frequentemente a causa real.
Um banco de dados sob estresse devido a corrupção, problemas de bloqueio ou restrições do servidor pode começar a falhar sob carga de escrita. Você pode ver um prompt genérico "Tem certeza de que deseja fazer isso?", uma tela branca, ou um post que parece ser salvo, mas não é.
Corrupção de tabela (que pode acontecer quando uma operação de banco de dados é interrompida) produz os mesmos sintomas.
Se você descartou conflitos de plugin e os erros continuam voltando, verifique a saúde do seu banco de dados antes de qualquer outra coisa.
Ferramentas de Teste de Velocidade Mostram Atrasos de "Aguardando Banco de Dados"
Ferramentas como GTmetrix mostram onde o tempo está sendo gasto durante o carregamento de uma página.
No GTmetrix, a barra roxa no gráfico de cascata representa "tempo de espera" — o tempo entre o navegador enviar uma solicitação e receber o primeiro byte de volta do servidor.

Uma barra roxa longa aponta para processamento lento do lado do servidor. Esse processamento inclui consultas ao banco de dados.
Quando tabelas fragmentadas levam mais tempo para serem escaneadas do que deveriam, consultas que deveriam ser executadas em menos de 10 milissegundos começam a se acumular. A barra roxa fica mais longa.
Um TTFB (Time to First Byte, o tempo entre uma solicitação do navegador e o primeiro byte de uma resposta) alto com tempo de resposta lento do servidor é um dos sinais mensuráveis mais claros de que seu banco de dados precisa de atenção.
O Carregamento de Páginas é Lento em Solicitações Não em Cache
O cache esconde problemas de banco de dados da maioria dos visitantes. Ele serve uma cópia armazenada da página em vez de consultar o banco de dados a cada vez. Mas o cache não cobre a todos.
Usuários administradores, editores e membros logados ignoram completamente o cache de página. Páginas de carrinho e checkout do WooCommerce também geralmente o ignoram. Se esses fluxos parecerem lentos, o banco de dados é provavelmente a causa.
Seus Backups São Maiores do que Deveriam Ser
O tamanho do backup é um reflexo direto do tamanho do banco de dados. O peso morto é copiado junto com todo o resto.
Um banco de dados com 100.000 revisões de posts e 50.000 transientes expirados adiciona megabytes reais a cada backup. Isso significa tempos de transferência mais longos, mais armazenamento em nuvem consumido e restaurações mais lentas se você precisar de uma.
A maioria das pessoas não percebe isso porque os backups são executados em segundo plano. Você só sente isso quando um backup expira ou uma restauração leva uma hora a mais do que o esperado.
Migrações Levam Mais Tempo do que o Esperado
Quando você migra um site WordPress, o banco de dados completo se move com ele. Cada linha órfã, transiente expirado e cópia de revisão faz a viagem.
Um banco de dados inchado produz um pacote de migração maior. Isso significa um upload mais lento, mais tempo para algo dar errado durante a transferência e uma situação mais complicada para depurar se a migração falhar.
A ordem correta é limpar o banco de dados primeiro, depois criar seu backup e, em seguida, migrar.
Seu Banco de Dados Tem Tabelas Órfãs ou Tamanho Desproporcional
Todo plugin que cria suas próprias tabelas de banco de dados as deixa para trás quando desinstalado — a menos que o desenvolvedor tenha escrito explicitamente código de limpeza.
Tabelas de plugins que você removeu anos atrás ainda podem estar em seu banco de dados. Elas ocupam espaço e adicionam desordem a cada consulta que escaneia sua lista de tabelas.
Se o seu banco de dados tem 500 MB, mas você tem apenas 300 posts, tabelas órfãs e lixo acumulado podem explicar a diferença.
A maioria dos painéis de hospedagem mostra o tamanho do seu banco de dados. Se você não verificou recentemente, vale a pena dar uma olhada.
Como é um Banco de Dados Saudável
Veja como é um banco de dados WordPress bem mantido:
- Dados carregados automaticamente abaixo de aproximadamente 800 KB a 1 MB, dependendo do site e da configuração de cache
- Sobrecarga de tabela em ou perto de zero após uma limpeza recente
- Transientes limpos ou expirando conforme o esperado
- Revisões de posts limitadas ou podadas periodicamente
- Nenhuma tabela restante de plugins desativados
A maioria dos proprietários de sites não tem como verificar essas coisas sem executar consultas SQL ou vasculhar o phpMyAdmin. Essa é a lacuna que o DB Optimizer preenche.
DB Optimizer é um plugin que dá ao seu banco de dados uma pontuação de saúde de 0 a 100. Ele avalia cinco categorias: sobrecarga de tabela, transientes, revisões, tamanho de autoload e itens de lixeira.

Cada categoria recebe sua própria barra de progresso e uma nota codificada por cores. Verde significa que você está em boa forma. Amarelo significa que algo precisa de atenção. Vermelho significa que é hora de limpar.

Otimize todo o seu banco de dados em massa com a guia Limpeza. O DB Optimizer limpa suas revisões de posts, comentários de spam, transientes, trackbacks e outros dados desnecessários.

Isso transforma a manutenção do banco de dados em uma tarefa simples que você pode realmente acompanhar.
Como Verificar a Saúde do Seu Banco de Dados Antes da Sua Próxima Migração
Se você está planejando uma migração, este é o momento certo para verificar a saúde do seu banco de dados. Não depois que a transferência demorar o dobro do tempo.
Abra o DB Optimizer e verifique sua pontuação de saúde. Olhe quais categorias estão verdes, amarelas ou vermelhas. Isso diz onde estão os problemas antes de você tocar em qualquer coisa.
Vá para a guia Limpeza. Antes de executar qualquer coisa, o DB Optimizer mostra o número total de itens disponíveis para limpeza e o espaço recuperável em todo o seu banco de dados. Você decide o que limpar e o que deixar.
Defina seu limite de retenção. O padrão é de 7 dias, o que significa que qualquer coisa criada na última semana está fora de alcance, independentemente dos tipos de limpeza que você selecionou.
Se você estiver sendo cauteloso, defina um valor mais alto. Se quiser um registro limpo antes de migrar, defina um valor mais baixo.

O DB Optimizer mostra contagens de itens e tamanho estimado para cada tipo de limpeza antes que qualquer coisa seja executada. Revise a lista, desmarque qualquer coisa que você queira manter e confirme quando estiver pronto.
O DB Optimizer detecta o Duplicator automaticamente e coloca um link direto para criar um backup logo ao lado dos controles de limpeza. Clique nele, pois você não vai querer perder nada importante.

Um banco de dados mais limpo significa um backup menor, uma transferência mais rápida e menos coisas para organizar se algo der errado.
Perguntas Frequentes (FAQs)
Como sei se meu banco de dados do WordPress está muito grande?
Verifique o tamanho do seu banco de dados no painel da sua hospedagem ou no phpMyAdmin. Um banco de dados significativamente maior do que o seu conteúdo real sugere acúmulo de inchaço. Se você tem algumas centenas de posts, mas seu banco de dados tem vários megabytes, tabelas órfãs, revisões de posts e transientes expirados são a causa provável. Verifique também seus dados autoload especificamente. Qualquer coisa acima de 800KB é um sinal de que a tabela wp_options precisa de atenção.
O inchaço do banco de dados afeta a velocidade do front-end?
Depende do que está inchado. Dados autoload impactam cada carregamento de página, independentemente do cache, porque o WordPress os carrega antes de atender a qualquer solicitação. Tabelas fragmentadas e alta sobrecarga afetam solicitações não cacheadas, que incluem usuários logados, páginas de checkout do WooCommerce e qualquer página que seu cache não atinja. Visitantes que acessam páginas cacheadas podem não notar nada. Todos os outros sentem.
Com que frequência devo otimizar meu banco de dados do WordPress?
Mensalmente para sites ativos com publicações regulares, mudanças frequentes de plugins ou transações do WooCommerce. Trimestralmente, no mínimo, para sites com menor tráfego. Sempre execute uma limpeza antes de uma migração importante ou uma atualização significativa do WordPress. Quanto mais tempo você esperar entre as limpezas, mais coisas haverá para organizar quando finalmente o fizer.
É seguro excluir revisões de posts?
Sim. Excluir revisões de posts remove cópias históricas do seu conteúdo, não a versão publicada. Seus posts ativos não são afetados. Dito isso, sempre faça um backup antes de executar qualquer limpeza de banco de dados. Se você excluir uma revisão que precisava, um backup é a única maneira de recuperá-la.
O que é sobrecarga de tabela no WordPress e isso importa?
Sobrecarga de tabela é espaço não utilizado deixado em uma tabela de banco de dados após a exclusão de linhas. O MySQL não recupera esse espaço automaticamente. Isso importa porque a sobrecarga desperdiça espaço em disco e força o MySQL a varrer lacunas vazias durante as consultas. Em um site muito utilizado com exclusões frequentes, a sobrecarga se acumula mais rápido do que a maioria das pessoas espera.
Limpar meu banco de dados quebrará meu site?
Não se você abordar com cuidado. Use um limite de retenção para manter dados recentes fora de alcance. Visualize exatamente o que será removido antes de confirmar. Faça um backup completo primeiro. A limpeza remove permanentemente registros do banco de dados sem um desfazer embutido, então o backup é o que lhe dá uma opção de recuperação se algo der errado.
O que causa erros ao salvar posts no WordPress?
Corrupção de tabelas do banco de dados e falhas de gravação sob estresse são duas causas comuns que muitas vezes são diagnosticadas incorretamente como conflitos de plugins. Um banco de dados fragmentado ou sobrecarregado pode falhar durante as operações de gravação, produzindo erros genéricos de salvamento ou telas brancas. Se você descartou conflitos de plugins e os erros continuam retornando, execute uma verificação de integridade do banco de dados antes de procurar em outro lugar.
Um Banco de Dados Inchado Não Se Corrige Sozinho
Os problemas de desempenho abordados neste post são reais, mas eles aparecem em tamanhos de backup e tempos de migração e velocidades de resposta do administrador, não no seu frontend. É por isso que eles são ignorados.
O custo aparece mais tarde. Uma migração que deveria levar 20 minutos leva duas horas. Um backup falha no meio da transferência porque o arquivo ficou muito grande. Um salvamento de post começa a gerar erros, e você passa uma tarde descartando conflitos de plugins quando o banco de dados precisava de uma limpeza.
A manutenção do banco de dados é fácil de adiar indefinidamente porque as consequências são invisíveis até que não sejam mais.
Uma verificação que vale a pena fazer agora, antes de instalar qualquer coisa: abra seu painel de hospedagem ou phpMyAdmin e veja o tamanho da sua tabela wp_options. Em um site WordPress típico, ela deve estar em algum lugar abaixo de 3 a 5 MB.
Se for 10 MB ou mais, os dados autoloaded são quase certamente o problema. Essa única tabela, quando inchada, adiciona sobrecarga a cada carregamento de página em todo o seu site, com cache ou não. É a maneira mais rápida de ter uma leitura aproximada se o seu banco de dados tem um problema que vale a pena resolver.
DB Optimizer mostra uma imagem mais completa. Ele oferece uma pontuação de integridade do banco de dados, uma prévia completa do que está disponível para limpeza antes que qualquer coisa seja executada e um limite de retenção configurável que mantém os dados recentes fora de alcance automaticamente.
O DB Optimizer está incluído no plano Duplicator Elite ao lado de WP Media Cleanup, Activity Log e Duplicator Pro. Quatro ferramentas para manter seu site WordPress saudável, com backup e pronto para mover quando você precisar.
Se este post fez você pensar sobre a saúde do seu banco de dados, estes guias valem a pena ler em seguida.
- Como Otimizar Seu Banco de Dados WordPress
- Aqui estão as etapas de reparo do banco de dados do WordPress que fiz pessoalmente (sem necessidade de desenvolvedor)
- Manutenção do Banco de Dados do WordPress: O Que Fazer Semanalmente, Mensalmente e Trimestralmente
- Como Fazer Backup de um Banco de Dados WordPress (Guia Completo)
- Como Restaurar um Banco de Dados do WordPress (3 Métodos)
- 13 Melhores Plugins de Banco de Dados do WordPress para Gerenciamento Fácil de Dados