Performance Tuning MySQL 8.4 — Guia Completo 2026.

MySQL 8.4 LTS estabilizou o que o 8.0 começou: hash join consolidado, replicação paralela WRITESET madura, performance_schema com overhead irrelevante e suporte estendido até 2032. Ainda assim, a configuração default continua sendo feita para que o MySQL "ligue" — não para que rode performático em produção. Este guia condensa a metodologia de consultoria MySQL que aplicamos em ambientes críticos: os seis pilares de tuning que respondem por 80% do ganho real de performance, com comandos, thresholds numéricos e os erros mais comuns que vemos em quem opera o banco sozinho.

A HTI mantém engenheiros que contribuem com o código-fonte do MySQL desde 2004 e opera mais de 1.000 servidores em produção. Tudo o que está aqui foi calibrado contra incidente real — não contra documentação genérica.

Os defaults do MySQL 8.4 evoluíram — binlog_transaction_dependency_tracking agora é WRITESET, innodb_log_writer_threads vem habilitado, autenticadores legados foram removidos. Mas o instalador continua sem ideia do seu hardware, do seu workload e do seu SLA. innodb_buffer_pool_size default ainda é 134217728 (128 MB). innodb_redo_log_capacity começa em 104857600 (100 MB). max_connections em 151. Isso é configuração para um laptop, não para um banco que sustenta receita.

O resultado prático: a aplicação "funciona" no primeiro dia, e seis meses depois — com mais dados, mais conexões e mais concorrência — começa a degradar de forma errática. O time de desenvolvimento culpa o banco, o time de infraestrutura culpa a aplicação, e ninguém olha onde dói: nos parâmetros que nunca foram tocados. Os seis pilares abaixo são a base do que ajustamos em qualquer Health Check de banco de dados.

O buffer pool é o cache que mantém páginas de dados e índices em RAM. Subdimensionado, todo acesso vira I/O de disco; superdimensionado em host compartilhado, vira swap — e swap é pior que I/O direto. Em servidor MySQL dedicado, 60–75% da RAM é o ponto de partida. O número correto vem da hit ratio real sob carga.

Thresholds práticos

Hit ratio acima de 99,9% e RAM ociosa = buffer pool bem dimensionado. Entre 99% e 99,9% em workload OLTP = considere aumentar. Abaixo de 99% = working set não cabe em RAM, e cada miss custa milissegundos. Em servidores com mais de 64 GB de RAM, configure innodb_buffer_pool_instances (8 a 16) para reduzir contenção de mutex.

MySQL 8.0 vs 8.4

No 8.4, o parâmetro aceita expressão percentual de forma mais previsível, e o resize online (sem restart) ficou mais estável — você pode subir de 32 GB para 64 GB sob carga sem janela de manutenção, desde que o host tenha RAM livre. No 8.0 essa operação ainda era de risco em produção.

"Buffer pool é o único parâmetro do MySQL onde 'um pouco mais grande' resolve mais problemas que cria — desde que você não bata em swap."

Slow query log desligado é o equivalente a operar sem instrumento. O default long_query_time = 10 é absurdo para 2026 — significa que só queries acima de 10 segundos são registradas. Em workload OLTP moderno, o alvo é o orçamento de latência do seu SLA, geralmente entre 0,1 e 0,5 segundo.

Para análise agregada, use mysqldumpslow ou — preferencialmente — pt-query-digest (Percona Toolkit), que gera ranking de fingerprints de query por tempo total, tempo médio e número de execuções. É comum descobrir que 80% do tempo do banco é gasto em 5 queries — e três delas têm correção trivial.

Erros comuns

Manter slow log em disco compartilhado com datafile, esquecer de rotacionar o arquivo (vimos slow logs de 200 GB ocupando toda a partição), e — o pior — coletar slow log e nunca olhar. Slow query log só vale o I/O extra se vira plano de ação semanal.

Índice composto bem feito resolve a maior parte dos problemas de slow query. A regra: a ordem das colunas no índice deve seguir o padrão de WHERE + ORDER BY e a seletividade real dos dados. EXPLAIN ANALYZE (8.0.18+) é o divisor de águas — diferente do EXPLAIN tradicional, ele executa a query e mostra o tempo real de cada operador.

Os erros que mais vemos

Função em coluna do WHERE (WHERE DATE(created_at) = ...) mata o uso de índice — substitua por functional index (8.0+) ou reescreva como range. Índices duplicados ((a) e (a, b) coexistindo, onde o primeiro é redundante) degradam writes em troca de zero benefício. Índices em colunas de baixíssima cardinalidade (status com 3 valores) raramente compensam — o otimizador prefere full scan.

Em tabelas acima de 500 milhões de linhas, considere particionamento por RANGE em coluna de data para viabilizar ALTER TABLE, manutenção e backup incremental dentro de janela. Particionamento mal feito, porém, piora performance — esse é o tipo de decisão que se beneficia de um DBA Remoto com histórico do ambiente.

O default max_connections = 151 é baixo para qualquer aplicação moderna. O reflexo de quem está apagando incêndio é subir para 1000, 2000, 5000. Funciona — até o servidor cair. Cada conexão MySQL consome memória (thread stack + buffers por sessão); 5.000 conexões ociosas podem comer 15–25 GB de RAM antes de qualquer query rodar.

Se Max_used_connections está perto do limite e Connection_errors_max_connections > 0, há um problema real. Mas, na maioria dos ambientes que auditamos, a causa raiz é pool de aplicação mal dimensionado, ausência de ProxySQL / MySQL Router fazendo connection multiplexing, ou queries longas segurando conexão. Aumentar max_connections sem resolver isso só atrasa o próximo incidente — e torna o crash maior quando vier.

Combinação recomendada

Pool de conexões na aplicação (HikariCP, PgBouncer-like para MySQL via ProxySQL) + wait_timeout e interactive_timeout reduzidos (300–600s em vez do default de 28800s) + max_connections dimensionado pelo pico real medido, não pelo medo. Em ambiente com alta concorrência e SLA 24/7, esse é o tipo de ajuste que entra no escopo de uma consultoria MySQL especializada — o time de consultoria MySQL especializada da HTI trata esse tipo de incidente como rotina.

Desde o MySQL 8.0.30, innodb_redo_log_capacity substituiu o velho par innodb_log_file_size × innodb_log_files_in_group. O default de 100 MB é absurdamente baixo para workload write-heavy. Em ambientes com escrita intensa (filas, logging, e-commerce com alta conversão), 8–16 GB é o ponto de partida.

innodb_flush_log_at_trx_commit é o trade-off mais direto entre durabilidade e throughput. 1 = ACID estrito, cada commit vai para disco (default e correto para a maioria). 2 = OS bufferiza, perde até 1s em crash de host. 0 = nunca, exceto em workload batch onde reprocesso é trivial. Mexer nesse parâmetro sem entender o RPO do negócio é uma das causas mais comuns de perda de dados em incidente.

MySQL 8.0 vs 8.4

No 8.4, innodb_redo_log_capacity aceita resize online estável (mesma lógica do buffer pool), e innodb_log_writer_threads = ON por default reduz contenção em workload write-heavy de alta concorrência. Em ambientes de 8.0 que ainda usam innodb_log_file_size, qualquer alteração ainda exige restart.

Tuning sem evidência é chute. performance_schema está habilitado por default no 8.x com overhead inferior a 5% em workload normal — não há justificativa técnica para deixá-lo desligado em 2026. Quem facilita o consumo é o sys schema, que entrega views prontas sobre os dados do performance_schema.

Esses quatro selects, rodados periodicamente, respondem por 80% das perguntas de tuning. O outro 20% — locks complexos, contenção de mutex em InnoDB, latência de network em replicação — exige instrumentação adicional via consumers específicos do performance_schema, e é onde entra a expertise dos especialistas em MySQL da HTI.

Use isto como base — não como dogma. Cada ambiente tem trade-offs próprios:

• Versão em MySQL 8.4 LTS (ou 8.0.x dentro do ciclo de suporte estendido).
• innodb_buffer_pool_size dimensionado por hit ratio real, alvo > 99,9%.
• innodb_buffer_pool_instances = 8–16 em servidores com mais de 64 GB de RAM.
• Slow query log ativo com long_query_time coerente com o SLA (0,1–0,5s em OLTP).
• Top 20 queries do pt-query-digest auditadas a cada release.
• Índices compostos seguindo padrão WHERE + ORDER BY; zero função em coluna do WHERE.
• sys.schema_unused_indexes revisado trimestralmente.
• max_connections calibrado por pico real + pool na aplicação + wait_timeout reduzido.
• innodb_redo_log_capacity ≥ 8 GB em workload write-heavy.
• innodb_flush_log_at_trx_commit coerente com o RPO do negócio.
• Replicação com binlog_transaction_dependency_tracking = WRITESET.
• performance_schema ativo + dashboards conectados ao sys schema.
• Backup com restore testado em ambiente isolado nos últimos 90 dias.
• Monitoramento ativo com plano de resposta — interno ou via DBA Remoto.

Performance tuning de MySQL tem um teto claro para quem opera o banco sozinho: o ponto em que cada hora de investigação custa mais do que o resultado entrega. Esse momento chega cedo em três cenários:

• Incidente em produção agora: banco lento, conexões estourando, deadlock recorrente. Aqui o tempo de resposta vale mais que o método — é caso de atendimento emergencial 24/7.
• Crescimento previsível batendo no teto: a aplicação dobrou de tráfego em 12 meses, e os mesmos parâmetros não escalam mais. É hora de auditoria estruturada + plano de capacidade — escopo típico de consultoria MySQL.
• Alta disponibilidade exigida por contrato: SLA contratual de 99,9% ou mais não se sustenta com tuning pontual; exige replicação bem desenhada, failover testado e cluster monitorado. Cobrimos esse cenário em detalhe em consultoria MySQL alta disponibilidade.

A HTI mantém engenheiros com mais de 35 anos de MySQL — contribuímos com o código-fonte desde 2004, somos AMEC Oracle, gerimos mais de 1.000 servidores em produção e resolvemos mais de 596 incidentes críticos só nos últimos anos. Não vendemos hora de tentativa: vendemos diagnóstico e correção baseados em recorrência.