Performance Tuning MySQL 8.4 — Guia Completo 2026.

Performance tuning de MySQL em 2026 não é mais sobre ajustar três parâmetros e esperar milagre. Com o MySQL 8.4 LTS estabilizado, hash join consolidado, replicação paralela WRITESET madura e performance_schema com baixíssimo overhead, o trabalho do DBA mudou: virou engenharia de capacidade baseada em evidência.

Este guia é o roteiro técnico que aplicamos quando entramos em um ambiente MySQL 8.4 com problema de performance — do buffer pool ao otimizador, passando por índices, redo log e monitoramento. É o complemento prático do nosso panorama de consultoria MySQL.

MySQL 8.4 é o primeiro LTS desde o 5.7 e marca o fim do modelo "innovation releases". Tem suporte estendido até abril/2032 — o que muda o cálculo de migração para qualquer ambiente em produção. As mudanças relevantes para tuning:

Defaults mais sensatos

innodb_buffer_pool_size agora respeita melhor a auto-configuração quando setado como percentual; innodb_log_writer_threads vem habilitado; binlog_transaction_dependency_tracking default mudou para WRITESET — replicação paralela de fato funcionando out-of-the-box. Defaults velhos como caching_sha2_password deprecated foram removidos.

Hash join consolidado

Hash join, introduzido no 8.0.18, está estável e o otimizador o escolhe com mais confiança em joins sem índice utilizável. Em queries analíticas, deixou de ser comum ver Using join buffer (Block Nested Loop) — substituído por Using join buffer (hash join), ordens de magnitude mais rápido.

Replicação Group Replication mais previsível

Communication stack do Group Replication foi reescrita com melhor recuperação de partição de rede. InnoDB Cluster passou a ser opção real para alta disponibilidade automatizada — assunto que aprofundamos no artigo sobre alta disponibilidade MySQL com InnoDB Cluster.

O buffer pool é o cache que mantém páginas de dados e índices em RAM. Subdimensionado, todo acesso vira I/O. Superdimensionado em host compartilhado, causa swap — pior que I/O direto. A regra de 60-70% da RAM é ponto de partida; o número real vem de medir.

Hit ratio abaixo de 99% em workload OLTP indica buffer pool insuficiente — ou working set maior que a RAM disponível. Em servidores com mais de 64GB de RAM, configure innodb_buffer_pool_instances (default 8 ou 1, depende da versão) para reduzir contenção de mutex.

Em MySQL 8.0.30+, innodb_redo_log_capacity substitui o velho innodb_log_file_size. O default de 100MB é absurdamente baixo para workload de escrita real. Em ambientes write-heavy, 8–16GB é 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), 2 deixa o OS bufferizar (perde até 1s em crash de host), 0 nunca usar exceto em workload batch onde reprocesso é trivial.

"Tuning de redo log é tuning de write throughput. Quem confunde isso, tuna o que não importa."

EXPLAIN ANALYZE (MySQL 8.0.18+) é o divisor de águas. Diferente do EXPLAIN tradicional, ele executa a query e mostra o tempo real de cada operador — tornando óbvio onde está o gargalo.

A saída traz actual time=X..Y rows=N loops=L em cada nó. Operações com actual time alto e número de loops grande são os primeiros suspeitos — normalmente nested loop sem índice ou hash join derramando para disco.

Índice composto resolve 90% dos problemas de slow query. A regra: ordem de colunas no índice deve seguir a seletividade e o padrão de WHERE + ORDER BY. Função em coluna no WHERE mata o uso de índice — substitua por functional index (8.0+) ou reescreva a query.

Em tabelas acima de 500 milhões de linhas, considere particionamento por RANGE (datas) para viabilizar ALTER TABLE, manutenção e backup incremental dentro de janela operacional. Particionamento mal feito, porém, piora performance — decida com dados, não com palpite.

Tuning sem evidência é chute. performance_schema está habilitado por default no 8.x com overhead inferior a 5% em workloads normais. As views mais úteis:

sys.statements_with_runtimes_in_95th_percentile — top statements lentos. sys.schema_unused_indexes — índices nunca usados (que ainda assim degradam writes). sys.io_global_by_file_by_bytes — qual arquivo está apanhando I/O. sys.waits_global_by_latency — quais waits dominam o tempo.

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

• Versão em 8.4 LTS (ou 8.0.x dentro do ciclo de suporte estendido).
• innodb_buffer_pool_size dimensionado com base em hit ratio real, não em chute.
• innodb_redo_log_capacity ≥ 8GB 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.
• Top 20 queries do sys.statements_with_runtimes_in_95th_percentile auditadas.
• EXPLAIN ANALYZE rodado em toda query crítica antes de ir para produção.
• Slow query log com long_query_time ajustado para o SLA do negócio.
• Backup com restore testado em ambiente isolado nos últimos 90 dias.
• DBA Remoto 24/7 ou monitoramento ativo cobrindo o ambiente.