Meu banco de dados está deixando meu site lento. Ele deve ter um servidor próprio?

Sua loja carrega bem logo cedo e se arrasta na hora do almoço. O painel do WordPress leva alguns segundos para abrir um produto, e um teste de velocidade entrega uma nota razoável com uma observação vaga sobre o tempo de resposta do servidor. Alguém num fórum diz que o problema é o banco de dados, e outra pessoa diz que um servidor maior resolve.

O próprio guia de banco de dados do WordPress da DreamHost explica que as ferramentas de velocidade online não conseguem acessar seu banco de dados, então um site pode tirar uma boa nota e ainda assim executar consultas lentas. Você precisa de um teste que olhe dentro da página enquanto ela está sendo montada. É isso que o Query Monitor faz.

Vamos por partes: descobrir se o MySQL é a parte lenta, corrigir o que der no servidor que você já tem e, depois, decidir se vale a pena ter um servidor MySQL privado e o que muda quando seus dados mudam de lugar.

Confirme se o banco de dados é a parte lenta

Você pode fazer todas as verificações abaixo pelo seu panel e pelo WordPress, sem direitos de administrador no servidor MySQL, e nenhuma delas altera seu site além da instalação de um plugin.

1. Descubra em qual servidor MySQL você está e onde ele fica

   Abra a página MySQL Databases no seu panel e confira o nome do servidor ao lado de cada banco de dados. O guia da DreamHost sobre logs de banco de dados explica os nomes: um que começa com iad1 é um servidor MySQL compartilhado, sql seguido de um número é um servidor MySQL privado, e ds é um servidor dedicado. Se o seu já começa com sql, você está num servidor privado, e os sinais de compra mais abaixo não se aplicam a você. Depois, abra a página Data Centers do panel. Seus servidores web e MySQL devem ficar no mesmo data center para reduzir o atraso de rede, e o suporte pode transferi-los se não estiverem.

2. Instale o Query Monitor e compare dois números

   O Query Monitor é um plugin gratuito que lista todas as consultas ao banco de dados de uma página e as agrupa por plugin, tema ou núcleo do WordPress. Faça login como administrador e abra uma página que pareça lenta. O menu do plugin na barra de ferramentas de administração mostra o tempo de geração da página e o tempo total gasto com consultas SQL, ambos em segundos. Compare os dois. Se o tempo das consultas for uma pequena parte do tempo de geração, outra coisa que não o banco de dados está segurando a página, como chamadas HTTP ou a renderização de blocos.

3. Encontre o plugin e as consultas por trás desse tempo

   Abra o painel Queries by Component. Ele é ordenado pelo tempo total, então o plugin ou tema com mais tempo de banco de dados fica no topo, e o autor do plugin diz que é por ali que se começa quando um site parece lento. O Query Monitor marca uma consulta como lenta quando ela passa de 0,05 segundo. Ele também sinaliza duplicatas, que geralmente indicam que o código está executando uma consulta dentro de um loop quando poderia consultar uma vez só e guardar o resultado em cache.

4. Carregue a mesma página em um horário tranquilo e em um horário de pico

   O Query Monitor não guarda histórico. Anote os números. Carregue a página lenta num horário tranquilo e depois de novo no seu horário de maior movimento, e compare o tempo total das consultas e os tempos das mesmas consultas lentas. O artigo da DreamHost sobre como melhorar o desempenho do banco de dados inclui lentidão nos picos de tráfego entre os sinais de que o banco de dados é o gargalo, e recomenda verificar também o uso do servidor nos horários de pico.

5. Confira o gráfico de uso nos mesmos horários

   Na Hospedagem web, a página Servers & Usage mostra gráficos de CPU, RAM e armazenamento como Low, Medium ou High no último dia, na última semana ou nas últimas duas semanas. O guia de uso da Central de Ajuda diz que a CPU e a RAM do servidor web são compartilhadas entre as contas, mas os gráficos mostram apenas o uso da sua conta. Uma leitura High aponta para o seu próprio PHP e seus plugins. Uma leitura normal indica que sua conta não é a que mais consome, mas não diz o quanto o resto do servidor está ocupado.

Agora, associe o que você viu a uma causa provável:

O que o MySQL compartilhado não mostra

No MySQL compartilhado, você não vê os logs do servidor, nem os de consultas lentas, e o guia da DreamHost sobre logs de banco de dados diz que o suporte também não pode obtê-los para você. Seu usuário do MySQL também não tem o privilégio PROCESS, então a lista de processos mostra apenas as suas próprias consultas, e ele não pode executar SET GLOBAL para alterar configurações do servidor.

Por isso, o log de consultas lentas de que fala o manual do MySQL está fora do seu alcance aqui: ele vem desativado por padrão, e só alguém com direitos de administrador no servidor pode ativá-lo. O limite padrão dele é de 10 segundos. O mesmo guia da Central de Ajuda diz que o suporte da DreamHost pode obter logs para você, mediante solicitação, num servidor MySQL privado. Num servidor dedicado, você mesmo tem acesso aos arquivos de configuração do MySQL.

Primeiro, corrija o problema onde ele está

Tudo isso funciona no plano que você já tem, antes de pagar por qualquer coisa.

Analise as consultas lentas com EXPLAIN. Copie uma consulta lenta do Query Monitor. Coloque EXPLAIN na frente dela e execute-a no phpMyAdmin. A documentação da instrução EXPLAIN do MySQL explica como ela mostra o plano que o MySQL vai usar, incluindo quais índices ele lê, e EXPLAIN ANALYZE executa a consulta e informa o tempo real. O MySQL compartilhado da DreamHost concede o privilégio INDEX, então você pode adicionar um índice quando o plano mostrar o MySQL varrendo uma tabela inteira. Anote qualquer índice que você adicionar a uma tabela do WordPress ou do WooCommerce para conferir se ele continua lá depois das atualizações.

EXPLAIN SELECT option_name FROM wp_options
WHERE autoload = 'yes' OR autoload = 'on';

Limpe as tabelas do próprio WordPress. Os passos de limpeza do banco de dados do WordPress da DreamHost são executados via SSH com o WP-CLI. Eles excluem transients, otimizam as tabelas, reduzem as revisões de posts e limpam as tabelas postmeta e commentmeta. Verifique o tamanho do autoload antes de tudo, porque o WordPress carrega essas opções em toda requisição, e menos de cerca de 600 KB é bom para a maioria dos servidores. Estes comandos vêm desse artigo:

wp transient delete --all
wp db optimize
wp db query "SELECT SUM(LENGTH(option_value)/1048576) as 'Autoload(MB)' FROM $(wp config get table_prefix)options WHERE autoload='yes' or autoload='on';"

Tabelas com muito overhead deixam as consultas lentas e podem fazer o servidor web atingir o tempo limite enquanto espera uma resposta. A opção Optimize table do phpMyAdmin elimina o overhead, como explica o guia de lentidão da DreamHost.

Ative o cache. A própria documentação de desempenho do WordPress diz que o cache é a forma mais rápida de melhorar o desempenho. Um plugin de cache de páginas entrega posts e páginas como arquivos estáticos, então a maioria das visitas nem chega ao MySQL. Depois, adicione um cache de objetos.

Na hospedagem compartilhada, a Central de Ajuda da DreamHost documenta o plugin Docket Cache como um cache de objetos persistente baseado em arquivos, e o OPcache, de que ele precisa, já vem ativado. Se você prefere não cuidar de cache, a hospedagem WordPress com cache integrado da DreamHost faz isso no próprio servidor.

Configurações no nível do servidor, como a memória do InnoDB, são outro assunto, que abordamos no nosso artigo sobre como ajustar o MySQL numa VPS.

Sinais de que o banco de dados precisa de um servidor próprio

A DreamHost descreve o MySQL compartilhado como adequado para bancos de dados otimizados e desempenho padrão de sites, e a MySQL VPS como feita para clientes que precisam de respostas mais rápidas do banco de dados ou que já superaram o MySQL compartilhado. A página da MySQL VPS também cita o limite do compartilhamento no FAQ: Um servidor compartilhado pode causar gargalos de desempenho quando há um tráfego excepcionalmente alto.

Consultas lentas, por si só, não significam que o MySQL compartilhado é o lugar errado, então só considere um servidor privado depois de fazer as correções acima e se estes sinais continuarem aparecendo mesmo assim:

• As mesmas consultas ficam mais lentas no horário de pico. Suas anotações do Query Monitor nos horários tranquilos e de pico mostram as mesmas consultas demorando claramente mais quando o tráfego está alto, mesmo depois da limpeza e do cache.
• Os erros de conexão continuam voltando depois que você confirmou o hostname e o suporte verificou o servidor. Uma MySQL VPS dá aos seus bancos de dados recursos que não são compartilhados com outros usuários. A DreamHost não publica limites de conexão para nenhum dos dois tipos de servidor, então não podemos dar um número.
• Seu aplicativo precisa de triggers ou stored routines. A Central de Ajuda da DreamHost diz que não é possível criar novos triggers no MySQL compartilhado e lista as stored routines como indisponíveis nele, e diz que uma MySQL VPS oferece suporte a ambos.
• Você precisa dos logs do MySQL para depurar. A Central de Ajuda da DreamHost diz que o suporte pode obtê-los num servidor MySQL privado.

Se nada disso se aplica, fique onde está. Uma resposta de 2009 no Stack Overflow defende ficar:

A resposta mais votada da mesma discussão, com 188 votos, defende o contrário, por motivos de escalabilidade e desempenho. Use seus próprios números do horário de pico para decidir.

O que muda quando o banco de dados é transferido

Se você tem medo de que um banco de dados remoto acrescente um salto de rede, seu site já tem um. A visão geral do MySQL da DreamHost mostra onde cada tipo de servidor MySQL roda:

É por isso que a Central de Ajuda da DreamHost orienta os clientes a nunca usar localhost como host do banco de dados. Adicionar uma MySQL VPS muda apenas onde o banco de dados fica, e seu site continua acessando-o pela rede. As histórias de fórum sobre banco de dados remoto vêm de configurações diferentes. Numa discussão do Server Fault, um site nos EUA usava um banco de dados na Ásia e respondia muito devagar até o banco de dados ir para um servidor local. A distância causou esse atraso, e é por isso que a verificação do data center vem primeiro nos passos acima.

A migração em si é feita pelo panel:

1. Faça backup de todos os bancos de dados
   Primeiro, exporte uma cópia de cada banco de dados.
2. Adicione um MySQL VPS pelo panel

   Se você já tem uma VPS na sua conta, use Add Service+ na página Servers & Usage. Se não tem, abra a página MySQL Databases e clique em Turn on a MySQL VPS!. As instruções da DreamHost para adicionar um MySQL VPS cobrem os dois caminhos. O provisionamento pode levar algumas horas.

3. Escolha uma noite tranquila para a migração

   A Central de Ajuda diz que a DreamHost transfere todos os bancos de dados da sua conta para o novo servidor à meia-noite no horário do Pacífico, e o panel mostra isso como uma mesclagem. Ela não diz se o seu site fica fora do ar durante a migração nem quanto tempo a migração leva. Adicione o servidor num dia em que a meia-noite do Pacífico seja um horário tranquilo para seus visitantes e, se precisar de uma resposta definitiva, pergunte ao suporte antes.

4. Procure bancos de dados que ficaram para trás

   Alguns bancos de dados podem acabar divididos entre o servidor compartilhado antigo e o novo, e o botão Move my databases! na página MySQL Databases reúne todos eles de novo em um só lugar.

5. Ajuste o hostname e teste de novo

   Abra a página MySQL Databases e compare o hostname exibido para cada banco de dados com DB_HOST no seu arquivo de configuração. Se forem diferentes, altere DB_HOST para que corresponda ao panel. Um hostname recém-adicionado pode levar até 4 horas para começar a funcionar, porque os hostnames de banco de dados são nomes DNS. Depois, carregue suas páginas lentas nos mesmos horários tranquilos e de pico e compare os tempos com suas anotações.

Depois da migração, algumas coisas funcionam de outro jeito:

• Você continua sem acesso root ou SSH. O MySQL VPS é gerenciado, então a manutenção, os patches de segurança e as atualizações do sistema operacional ficam por conta da DreamHost, e as configurações do MySQL continuam sendo definidas pela DreamHost. Se você precisa dos arquivos de configuração ou se o seu aplicativo transfere grandes volumes de dados de e para o MySQL, a DreamHost indica um servidor dedicado, em que o MySQL roda na mesma máquina.
• A RAM pode aumentar depois. Você pode aumentar a RAM pelo panel a qualquer momento, e a Central de Ajuda diz que você recebe um crédito proporcional pelo plano antigo.
• Você pode ver se seus dados cabem na memória. Execute SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; e calcule 1 menos Innodb_buffer_pool_reads dividido por Innodb_buffer_pool_read_requests. Em um servidor que roda apenas seus bancos de dados, esse resultado é a parcela de leituras atendidas pela memória, o número que aparece na tabela de dimensionamento abaixo. No nosso MySQL de teste, um usuário com permissão em um único banco de dados conseguia ler esses contadores, mas não SHOW ENGINE INNODB STATUS.
• Voltar atrás tem um limite de tamanho. Se você não tiver um servidor dedicado, cada banco de dados no MySQL VPS precisa ter menos de 3 GB para que você possa excluir o servidor pelo panel. Depois, você escolhe um servidor de destino, e a DreamHost transfere seus dados para o servidor de banco de dados compartilhado em até 24 horas.

Qual opção é a ideal

Escolha o caminho que corresponde ao que suas verificações mostraram.

Para o caminho do MySQL VPS, comece pelo VPS business. A página da DreamHost o identifica como Built for Small Business, e a lista de planos do panel da DreamHost indica 1 GB de RAM e 20 GB de armazenamento para ele. O VPS basic é o nível abaixo. A página identifica o VPS basic como For new & small websites, o que combina com um site pequeno cujo principal motivo para migrar são triggers, rotinas ou logs. O VPS basic tem 500 MB de RAM na lista de planos da DreamHost. No nosso teste, o MySQL com as configurações padrão parou num limite de 512 MB sob carga, mesmo com um banco de dados pequeno. A própria DreamHost configura o MySQL em cada plano e não publica as configurações do VPS basic, então pergunte ao suporte para que ele serve antes de migrar um banco de dados movimentado para lá.

Antes de escolher, descubra o tamanho dos seus bancos de dados. O guia da DreamHost sobre otimização de banco de dados traz esta consulta para isso. Conecte-se ao banco de dados por SSH e execute-a para ver os dados e os índices de cada banco em MB:

SELECT table_schema "database", sum(data_length + index_length)/1024/1024 "size in MB" FROM information_schema.TABLES GROUP BY table_schema;

Se o total passar bem da RAM do plano, o MySQL não consegue manter tudo na memória, então comece um tamanho acima.

Quantos dados 1 GB comportou na nossa VM de teste

Testamos essa regra antes de confiar nela. Em uma VM de teste, demos ao MySQL 8.4 um limite rígido de memória do tamanho de cada plano do MySQL VPS, com o cache em cerca de metade disso, e rodamos uma carga constante, parecida com a de um site, em três tamanhos de banco de dados. A tabela mostra quantas leituras o MySQL respondeu a partir da memória e quanto tempo levaram os 5% de transações mais lentas. Cada transação é um lote de leituras e gravações, mais ou menos como uma visualização de página.

Um banco de dados com menos da metade da RAM do plano continuou rápido. Quando os dados passaram da RAM, as transações mais lentas ficaram mais lentas: 18,6 ms para o banco de 1,8 GB com 1 GB, contra 8,7 ms no plano acima. Com 4,6 GB em 1 GB, o MySQL simplesmente não deu conta da carga. Um limite de 512 MB, próximo dos 500 MB do VPS basic, foi pequeno demais para o MySQL com as configurações padrão: ele usou cerca de 470 MB antes de qualquer consulta rodar, e todas as execuções pararam no limite.

Essas são as nossas configurações de teste, não as da DreamHost. A DreamHost configura o MySQL em cada plano e não publica o tamanho do cache, e você não pode alterar as configurações de servidor do MySQL em um MySQL VPS. Use a tabela como referência de quantos dados cada tamanho de memória comporta com folga. O teste completo, com todos os tamanhos de cache que experimentamos, está no nosso guia sobre quanta RAM o MySQL precisa.

Não temos como dizer quantos visitantes cada plano suporta, porque isso depende mais das suas consultas do que do seu tamanho. Se os tempos no horário de pico voltarem a subir conforme seus dados crescem, aumente a RAM pelo panel.

Como testamos a questão da memória

Os números de memória foram medidos pela DreamHost em uma VM de teste (arm64), não em um servidor da DreamHost. Um limite rígido de memória fez o papel da RAM de cada plano do MySQL VPS. Fizemos a execução em 19 de outubro de 2026 para o nosso guia de dimensionamento de RAM, e esta página reaproveita os resultados. A VM rodava Ubuntu 24.04 no Colima em um Mac, com 2 vCPU e sem swap. O MySQL 8.4.11 rodou a partir da imagem oficial do Docker com as configurações padrão, exceto pelo tamanho do cache. O sysbench gerou uma carga mista de leitura e gravação concentrada em um núcleo de linhas muito acessadas, com 8 threads a 360 transações por segundo constantes, e uma janela de medição de 3 minutos após o aquecimento.

A página do MySQL VPS informa o MySQL 8.0, e o artigo da Central de Ajuda da DreamHost Using reserved words in MySQL 8 diz que, em uma VPS, você pode pedir ao suporte um upgrade para o MySQL 8.4. Testamos o 8.4, então um servidor que ainda está no 8.0 pode ter resultados um pouco diferentes.

O que não testamos: as configurações do MySQL VPS da própria DreamHost, o MySQL compartilhado, os tempos do Query Monitor em uma conta real, a rede entre um servidor web e um MySQL VPS, tabelas do WordPress ou do WooCommerce e quanto tempo a migração leva. Cada célula foi executada uma vez. As etapas de diagnóstico e os detalhes dos produtos vêm da Central de Ajuda e das páginas de produto listadas nas fontes.

Perguntas frequentes sobre banco de dados lento