Percona Server 8.4.11 melhora TPS em cenários I/O bound do MySQL

A Percona publicou em 27 de agosto de 2026, no seu Database Blog, uma investigação de performance assinada por Bogdan Degtyariov comparando três versões do Percona Server for MySQL↳MySQL8 conteúdosMySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Banco de dados MYSQL no PHPStormDev (Back & Front) · jul 2019Criando um ambiente de desenvolvimento PHP mínimo com Docker – Parte 3Dev (Back & Front) · out 2019Ver tudo em Data → 8.4 lançadas ao longo de 2026: a 8.4.8-8 (12 de março), a 8.4.10-10 (30 de junho) e a 8.4.11-11 (20 de agosto). O objetivo é direto e útil para quem opera banco em produção: medir se vale a pena atualizar, onde os ganhos aparecem e por quê. Recursos novos e patches de segurança ficaram deliberadamente de fora da análise, assim como latência (percentis) e utilização de recursos (CPU, RAM, I/O). O foco é uma métrica só: throughput (TPS) em OLTP read-write.

A metodologia importa mais que o número final

Antes de olhar qualquer resultado, convém entender o desenho do teste, porque é ele que dá sentido à comparação. A carga foi gerada com Sysbench OLTP Read-Write, sobre um servidor robusto: Intel Xeon Gold 6230 (2×20 núcleos, 80 CPUs lógicas com Hyper-Threading), 187 GiB de RAM DDR4, NVMe SSD Intel de 2,9 TB, Ubuntu 24.04.

O ponto central do método é cruzar três variáveis de forma controlada:

• Tamanho da base: 24 GB (100M linhas), 48 GB (200M) e 96 GB (400M), sempre com 20 tabelas.
• Concorrência: de 1 a 512 threads (1/4/16/32/64/128/256/512).
• Razão buffer/dados: 1:12 (I/O bound), 1:2 (parcialmente em memória) e 1:1 (totalmente em memória).

A razão buffer/dados é o eixo mais interessante. Ela isola o comportamento do innodb_buffer_pool_size frente ao volume de dados. No cenário 1:12, por exemplo, testaram buffer_pool de 2G para 24GB de dados, 4G para 48GB e 8G para 96GB. Assim dá para ver como o servidor se comporta com bases cada vez maiores mantendo a mesma proporção de cache.

Um detalhe de engenharia merece destaque, porque separa benchmark sério de número solto: a Percona travou a frequência de turbo da CPU em 2400 MHz desde o início. O Xeon 6230 tem base de 2100 MHz e turbo de 3900 MHz, mas o turbo só se sustenta por pouco tempo em núcleo isolado. Sob carga máxima em todos os núcleos, alguns servidores seguravam 2530 MHz por mais de 20 horas, outros só 2420 MHz. Fixar o teto eliminou a briga entre o turbo tentando subir e a proteção térmica derrubando o clock, reduzindo a variação entre execuções. É o tipo de cuidado que garante que a diferença medida vem do software, não do silício.

A configuração do InnoDB usada é a de um servidor OLTP levado a sério: innodb_flush_log_at_trx_commit = 1 (ACID completo), innodb_doublewrite = ON, innodb_flush_method = O_DIRECT, innodb_redo_log_capacity = 4G, thread pool com thread_pool_size = 80 casando a contagem de núcleos físicos, e binlog desabilitado (disable_log_bin = ON) para isolar a carga do banco. Cada combinação rodou três vezes, com janela de medição de 15 minutos.

Onde a 8.4.11 dispara: alta concorrência com I/O

O resultado que salta aos olhos está no cenário mais pressionado: 1:12 (I/O bound), buffer de 8G contra 96GB de dados. Quando o número de threads ultrapassa os 80 núcleos físicos (128 e acima), as versões 8.4.8-8 e 8.4.10-10 sofrem degradação abrupta de performance depois do ponto de saturação, que ocorre por volta de 64 threads. A 8.4.11-11, ao contrário, continua subindo o TPS.

Segundo o texto, isso se deve a uma otimização no algoritmo de flushing das páginas LRU do InnoDB, mirando exatamente o caso em que os dados são maiores que os buffers disponíveis e há muitas conexões concorrentes fazendo leitura e escrita aleatórias. A Percona promete detalhar o mecanismo em um post separado.

Há também um ganho mais discreto, mas relevante, entre a 8.4.8-8 e a 8.4.10-10, sobretudo no ponto de saturação com 64 threads. Esse a Percona atribui à introdução do Performance Guided Optimization (PGO), técnica de compilação em que o binário é otimizado a partir de dados de perfil de execução real. A 8.4.10-10 foi mais rápida que a 8.4.8-8 em todos os testes e configurações, o que faz do PGO um ganho consistente, ainda que menos espetacular que o flushing da 8.4.11.

O buffer pool não é só uma razão, é um tamanho absoluto

A análise do cenário 1:2 traz uma lição de modelagem de capacidade que costuma passar batida. Com buffer_pool de 12G e 24GB de dados, a vantagem da 8.4.11-11 sobre as anteriores continua enorme. Mas subindo para 24G/48GB o gap encolhe, e para 48G/96GB encolhe ainda mais, mesmo mantendo a razão 1:2 em todos os três.

A conclusão do autor é explícita: a performance não depende apenas da proporção entre buffer e dados, mas também do tamanho absoluto do buffer. Para quem dimensiona infraestrutura, isso desmonta a heurística preguiçosa de raciocinar só por percentual de cache. Dois servidores com a mesma razão buffer/dados podem entregar throughput bem diferente conforme os valores absolutos.

Onde a 8.4.11 NÃO é a melhor escolha

Aqui está o trade-off que o artigo tem a honestidade de expor. No cenário totalmente em memória (1:1), a 8.4.10-10 fica ligeiramente à frente da 8.4.11-11, embora o gap seja pequeno. E, mais importante: nesse caso o MySQL upstream é mais rápido que qualquer versão do Percona Server.

A leitura correta é a seguinte. O patch da 8.4.11-11 foi desenhado especificamente para resolver o fato de o Percona Server ser mais lento que o MySQL em cenários I/O bound, e para eliminar aquela queda brusca acima de 64 threads. Ele não faz parte do MySQL 8.4.11 upstream. Nas cargas em que o Percona Server perdia (poucas threads, I/O bound), a 8.4.11-11 passou a brilhar. Mas quando o dataset inteiro cabe na RAM, a otimização de flushing perde relevância, porque quase não há flushing sob pressão, e o upstream retoma a dianteira.

Ou seja: a decisão de upgrade não é universal. Para quem tem base grande que não cabe no buffer pool e alta concorrência, o caso a favor da 8.4.11-11 é forte. Para quem roda dataset pequeno totalmente bufferizado, o ganho some, e a escolha entre Percona Server e MySQL upstream passa a depender de outros fatores (as features e patches que este benchmark, por método, ignorou).

O que o DBA brasileiro leva disso

O benchmark reforça um princípio antigo: performance nasce do desenho, e o desenho começa por entender a relação entre o working set e a memória disponível. Antes de trocar de versão atrás de TPS, o profissional precisa saber em qual dos três regimes seu banco opera hoje. Um SHOW ENGINE INNODB STATUS e o monitoramento da taxa de hit do buffer pool dizem se a carga é I/O bound ou não, e essa resposta define se o ganho da 8.4.11 vai se materializar em produção ou ficar só no gráfico.

Vale registrar o que o próprio autor delimita: latência por percentil e consumo de recursos ficaram fora. Em produção OLTP, TPS médio não conta a história toda, um p99 ruim derruba SLA mesmo com throughput alto. Quem for avaliar upgrade faria bem em reproduzir o teste com sua própria carga e medir também a cauda da latência. A Percona disponibiliza o schema (schema_dump.sql) e os arquivos de configuração de cada execução nos gráficos interativos do post, o que permite replicar a metodologia em vez de confiar cegamente no resultado alheio, exatamente o tipo de rigor que separa decisão de infraestrutura de aposta.

Fonte: Percona Database Blog