Quanta RAM o MySQL precisa e qual o tamanho ideal do buffer pool?

Este guia ajuda você a dimensionar um MySQL VPS, o complemento para sites que já estão na hospedagem da DreamHost. O MySQL VPS tem quatro tamanhos, com 500 MB, 1 GB, 2 GB ou 4 GB de RAM, segundo a lista de planos do panel da DreamHost. Para ver de qual tamanho um banco de dados precisa, rodamos bancos de dados de 460 MB, 1,8 GB e 4,6 GB com a memória de cada plano em uma VM de teste (não um servidor da DreamHost) e contamos quantas leituras o MySQL atendeu pela memória. Uma resposta aceita no Server Fault define o cache do MySQL em cerca de 80% da memória do servidor. Nossos resultados abaixo mostram onde isso dá errado em servidores pequenos. Se, em vez disso, você roda seu próprio servidor de banco de dados em um VPS, os mesmos números mostram onde definir o tamanho do buffer pool.

O banco de dados inteiro não precisa caber na RAM. Matthew Boehm, que responde pela Percona no fórum da empresa, disse a um usuário que perguntou que um banco de dados de 4 TB pode rodar com 2 GB de RAM a cerca de 100 consultas somente leitura por segundo. Se você ainda não confirmou que é o banco de dados que deixa suas páginas lentas, já que um plugin lento ou a falta de cache de página podem parecer iguais vistos de fora, comece pelo nosso guia sobre como descobrir se o banco de dados está deixando seu site lento.

O que o MySQL guarda no buffer pool do InnoDB

A maior parte vai para um único cache. O InnoDB, o mecanismo que armazena suas tabelas, guarda dados de tabelas e índices no buffer pool à medida que os lê. Se os dados de que uma consulta precisa já estão lá, o MySQL responde a partir da memória. Se não estão, o MySQL vai ao disco. Algo mais antigo é descartado para abrir espaço. O manual do MySQL alerta que um pool pequeno demais fica descartando páginas de que vai precisar de novo um instante depois.

O tamanho dele é uma configuração, innodb_buffer_pool_size. O padrão do MySQL é 128 MB em qualquer servidor. Com a configuração automática para uma máquina que roda apenas o MySQL, o MySQL mantém 128 MB quando há menos de 1 GB de memória e usa metade da memória entre 1 GB e 4 GB. A DreamHost não publica o tamanho de cache que cada plano usa, e um MySQL VPS não tem acesso root nem SSH, então não é você quem altera essa configuração.

O restante da memória do MySQL não diminui com o plano. Na nossa VM de teste, o MySQL 8.4 com as configurações de fábrica usava cerca de 470 MB antes de qualquer consulta, com um cache de apenas 128 MB. A própria contagem do MySQL mostrou para onde ia: além do cache, um log buffer de 64 MB e cerca de 150 MB para o Performance Schema, o rastreador de atividade embutido do MySQL. Sob carga, depois que o cache encheu, o processo do servidor ocupou cerca de 450 a 740 MB além dele. Em um servidor de 4 GB, é uma fatia pequena. Em 1 GB, é a maior parte da memória.

O que medimos com a RAM de cada plano

A DreamHost fez este teste em 19 de outubro de 2026 em uma VM de teste (arm64, 2 vCPUs), com um limite rígido de memória igual à RAM de cada plano. Não é um servidor da DreamHost, então leia os resultados como o que a memória de cada plano consegue comportar.

Avaliamos cada execução pela taxa de acerto, a fração das leituras que o MySQL respondeu a partir do cache. Um banco de dados cabe quando 99% ou mais das leituras vêm da memória e o MySQL não trava. Entre 95% e 99%, fica apertado. Abaixo de 95%, a memória é pequena demais. A linha dos 95% é de Boehm: com 95% ou mais, segundo ele, você tem memória suficiente. A linha dos 99% é nossa, um critério mais rigoroso.

No banco de dados de 1,8 GB, isso significa que cerca de 35 de cada 1.000 leituras foram ao disco com 1 GB, 17 com 2 GB e 1 com 4 GB.

O tamanho do buffer pool importou tanto quanto a RAM. Veja o banco de dados de 1,8 GB com 2 GB de memória em cada tamanho de pool que testamos:

Com o padrão de 128 MB do MySQL, as taxas de acerto ficaram entre 92% e 96% em todos os limites, de 1 GB a 4 GB. Um cache de cerca de metade da RAM nunca travou. Com cerca de três quartos, o MySQL travou em 1 GB e 2 GB assim que o banco de dados ficou maior que o cache, porque a parte fixa acima dele não tinha para onde ir. Em 4 GB, três quartos rodaram sem problemas. Em um servidor que você mesmo administra, isso faz de cerca de metade da RAM o ponto de partida seguro para innodb_buffer_pool_size em 1 GB e 2 GB, deixando três quartos para servidores de 4 GB ou mais, com base nas nossas execuções únicas.

Um limite de 512 MB foi pequeno demais para as configurações de fábrica do MySQL 8.4. O MySQL usou cerca de 470 MB desse limite antes de qualquer consulta, e cada teste parou ao atingir o limite, mesmo com o banco de dados de 460 MB. O VPS basic tem 500 MB na lista de planos do panel da DreamHost, e a página do MySQL VPS informa que o servidor vem pré-configurado. Um servidor configurado para usar menos memória pode se sair melhor que o nosso, com as configurações de fábrica. A DreamHost não publica as configurações do VPS basic, então pergunte ao suporte para que tipo de uso ele serve antes de colocar nele um banco de dados muito acessado.

Por que a parte mais acessada importa mais que o total

Na mesma resposta, Boehm estima a parte ativa em cerca de 10% a 20% do total e diz que isso é típico. Uma loja com três anos de pedidos lê os pedidos deste mês e os produtos ativos com muito mais frequência do que uma fatura de 2023. Nossa carga de teste funcionava do mesmo jeito: voltava sempre a um núcleo de linhas muito acessadas, e foi assim que um banco de dados de 4,6 GB obteve 97,7% das leituras de um cache de 2 GB.

Um relatório que soma todos os pedidos desde o lançamento deixa todas essas linhas ativas ao mesmo tempo. Não testamos esse pior cenário, então não podemos dizer quanto o resultado cairia. Se o seu site depende de busca, relatórios ou exportações sobre dados antigos, considere as linhas da tabela como o melhor cenário e escolha um plano acima.

Verifique seu banco de dados antes de escolher

Nas duas primeiras etapas, você só vai precisar do panel e do phpMyAdmin, e elas funcionam no plano que você tem agora.

1. Descubra em qual servidor MySQL você está

   Abra a página MySQL Databases no seu panel e veja o nome do servidor no topo. O artigo da Central de Ajuda da DreamHost sobre como visualizar os logs do banco de dados explica os nomes: um que começa com iad1 é MySQL compartilhado, e sql seguido de um número significa que você já está em um servidor MySQL privado.

2. Meça o tamanho dos seus bancos de dados

   Execute esta consulta na aba SQL do phpMyAdmin ou via SSH. Ela vem do artigo da Central de Ajuda da DreamHost sobre como otimizar um banco de dados e mostra os dados e índices de cada banco de dados em MB.

   sqlCopiar

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

3. Encontre a linha que corresponde ao total

   Some todos os bancos de dados da sua conta, já que a Central de Ajuda da DreamHost diz que todos eles são movidos para o novo MySQL VPS. Encontre esse total na tabela acima. Se ficar entre duas linhas, escolha o plano da linha maior. Isso deixa espaço para os dados crescerem. Não medimos bancos de dados reais de WordPress ou WooCommerce, então o número a usar é o seu próprio total.

4. Verifique a taxa de acerto depois da migração

   Um MySQL VPS roda apenas os seus bancos de dados, então os contadores dele descrevem só os seus bancos. Leia Innodb_buffer_pool_read_requests e Innodb_buffer_pool_reads com SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; e calcule 1 menos as leituras divididas pelas solicitações de leitura. SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; mostra o tamanho de cache que o seu plano recebeu, em bytes, para você comparar com a tabela. Na nossa VM de teste, um usuário com permissão em um único banco de dados conseguiu ler os dois. No MySQL compartilhado, os contadores cobrem todos os bancos de dados daquele servidor, e é por isso que esta verificação fica para depois da migração.

Quando migrar para um plano maior

Migre para um plano maior quando a taxa de acerto cair abaixo de 95% e continuar assim à medida que seus dados crescem. A página do MySQL VPS informa que você pode aumentar a RAM pelo painel de controle do MySQL VPS, e a Central de Ajuda da DreamHost diz que a parte não utilizada do plano antigo vira crédito para o novo.

Não pague por memória antes de olhar suas consultas mais lentas. Mais adiante na mesma discussão da Percona, o relatório de ajustes de um usuário mostrava uma taxa de acerto de 100% ao lado de milhões de joins que não usavam nenhum índice, e a resposta de Boehm foi curta: No amount of ram will fix a bad query. Nosso guia sobre como encontrar consultas lentas no MySQL mostra como encontrá-las com o Query Monitor e o EXPLAIN. Para ajustar um servidor MySQL que você mesmo administra, veja nosso post sobre como melhorar o desempenho do banco de dados em um VPS.

Mais de 4 GB de dados acessados com frequência

Se a parte muito acessada dos seus dados ultrapassar os 4 GB do VPS enterprise, a DreamHost tem duas opções maiores para ela. Um servidor dedicado vem com 16 GB de RAM ou mais e roda o MySQL na mesma máquina que o seu site. A visão geral do MySQL da Central de Ajuda da DreamHost diz que isso é indicado para softwares que movimentam grandes volumes de dados entre o aplicativo e o MySQL, e a página do MySQL VPS diz que nele você tem acesso aos arquivos de configuração do MySQL. Se você preferir rodar seu próprio servidor de banco de dados, um VPS chega a 32 GB de RAM no Stack 32, em que você instala o MySQL e define o buffer pool por conta própria.

Se você está considerando um banco de dados na nuvem, nosso guia sobre preços do RDS for MySQL comparados aos de um servidor MySQL privado mostra o custo dos dois.

Como medimos

A DreamHost fez o teste em 19 de outubro de 2026, no Ubuntu 24.04.4 sob o Colima, em um Mac com Apple silicon: arm64, 2 vCPUs e sem swap. O MySQL 8.4.11 rodou a partir da imagem oficial do Docker com as configurações padrão, exceto o tamanho de cache em teste e duas opções que desativamos (salvar o cache entre reinicializações e o log binário). Um limite de memória do Docker de 512 MB, 1 GB, 2 GB ou 4 GB representou cada plano. Cada banco de dados era formado por tabelas do sysbench, com 1 milhão de linhas cada. O sysbench 1.0.20 gerou uma carga mista de leitura e escrita que favorece um núcleo de linhas muito acessadas, com 8 threads a 360 transações por segundo constantes. Cada execução teve um aquecimento de 2 minutos (5 para o banco de dados de 4,6 GB) e uma janela medida de 3 minutos. Cada cache foi testado com 128 MB, cerca de metade e cerca de três quartos da memória.

O teste tem limitações. Um MySQL VPS roda no próprio contêiner Linux no hardware da DreamHost, e o tamanho de cache, o limite de conexões e o swap que a DreamHost usa em cada plano não são publicados, então você não verá números idênticos em um MySQL VPS. Cada configuração rodou uma vez, então não podemos mostrar quanto uma repetição variaria, e diferenças pequenas podem ser ruído. Não testamos o pior cenário, em que todas as linhas são igualmente acessadas, não medimos a memória por conexão, não dimensionamos bancos de dados reais de WordPress ou WooCommerce nem testamos o MySQL 8.0.

Perguntas frequentes sobre memória do MySQL