Um analista de infraestrutura utiliza o MySQL com o storage engine InnoDB para suportar um sistema de consultas processuais que exige alta taxa de leitura e garantia de integridade transacional. O DBA percebeu que o disco está sendo lido e escrito excessivamente (I/O Bound) durante os picos de acesso, apesar de a CPU não estar sobrecarregada, indicando uma ineficiência no caching dos dados.
Considerando as práticas de otimização de desempenho e o storageengine InnoDB, a ação técnica mais imediata para mitigar o problema de I/O excessivo e melhorar o desempenho geral do banco de dados que o analista recomenda é:
ADesabilitar o Binary Logging (binlog) do MySQL para reduzir o número de operações de escrita em disco, e mudar todas as transações para o nível de isolamento READ UNCOMMITTED para eliminar os locks e deadlocks.
BAumentar o parâmetro innodb_buffer_pool_size no arquivo de configuração (my.cnf) para que ele utilize a maior parte da memória RAM disponível do servidor. Isso garante que os dados e índices mais frequentemente acessados sejam armazenados na memória, reduzindo drasticamente as operações de I/O em disco.
CConverter todas as tabelas InnoDB para o storage engine MyISAM, pois ele é o motor padrão do MySQL e possui um cache de índices mais eficiente, além de ser conhecido por oferecer um desempenho superior em operações de SELECT.
DImplementar uma política rigorosa de sharding (fragmentação horizontal) do banco de dados imediatamente. Essa solução, embora complexa, é a única capaz de resolver problemas de I/O excessivo, independentemente do uso da memória RAM.
EDiminuir o valor do parâmetro innodb_flush_log_at_trx_commit para 0 e configurar o parâmetro max_connections para o dobro do seu valor atual. Essas ações são suficientes para aumentar a concorrência e o throughput do sistema sem impacto na durabilidade das transações.
Revelar gabarito e comentário▾
GabaritoB — Aumentar o parâmetro innodb_buffer_pool_size no arquivo de configuração (my.cnf) para que ele utilize a maior parte da memória RAM disponível do servidor. Isso garante que os dados e índices mais frequentemente acessados sejam armazenados na memória, reduzindo drasticamente as operações de I/O em disco.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Otimização de desempenho no MySQL InnoDB: o papel do buffer pool
Gabarito: letra B. O sintoma descrito — disco lido e escrito excessivamente com CPU ociosa — é a assinatura clássica de um buffer pool subdimensionado: o InnoDB precisa buscar páginas de dados e índices no disco a cada acesso porque a memória disponível para cache é pequena demais. A ação imediata e de maior impacto é aumentar o innodb_buffer_pool_size, fazendo com que os dados e índices mais acessados fiquem residentes em memória RAM, o que reduz drasticamente as operações de I/O. É a prática recomendada pela documentação oficial do MySQL para cenários de I/O bound em InnoDB.
O InnoDB é o storage engine transacional padrão do MySQL desde a versão 5.5, e sua arquitetura gira em torno de um grande buffer pool em memória. Esse pool armazena páginas de dados, índices, o change buffer e estruturas internas de lock. Quando uma consulta precisa de uma página que não está no buffer pool, o InnoDB a lê do disco — e é exatamente essa leitura de disco que domina o tempo de resposta em workloads de leitura intensa. Se o buffer pool é pequeno, a taxa de cache hit cai, e cada acesso a uma página diferente gera I/O físico. O mesmo vale para escritas: o InnoDB usa o buffer pool para acumular modificações e só depois as grava em disco de forma otimizada (via flush). Portanto, um buffer pool generoso ataca as duas pontas do problema: reduz leituras de disco e suaviza o fluxo de escritas.
A regra prática amplamente difundida é configurar o innodb_buffer_pool_size para algo entre 70% e 80% da memória RAM total do servidor, reservando o restante para o sistema operacional, conexões, caches de consulta e outros processos. Em servidores dedicados ao MySQL, esse percentual pode chegar a 90%. O ajuste é feito no arquivo my.cnf (ou my.ini no Windows), na seção [mysqld], e exige reinicialização do serviço para ter efeito (ou pode ser alterado dinamicamente com SET GLOBAL em versões recentes, mas o valor persistente deve ficar no arquivo de configuração).
Vale destacar que o problema descrito não é de concorrência nem de durabilidade — é de cache. Por isso, soluções que mexem em isolamento, log binário ou nível de flush atacam sintomas errados e, pior, comprometem garantias que o sistema exige (integridade transacional). A banca explora exatamente essa confusão: o candidato que sabe que innodb_flush_log_at_trx_commit afeta escrita em disco pode achar que reduzi-lo é a saída, mas isso sacrifica durabilidade — algo inaceitável para um sistema que "exige garantia de integridade transacional".
Guarde o critério decisivo: I/O bound + InnoDB + alta taxa de leitura = aumentar o buffer pool. É essa a lente que separa a alternativa correta das demais, que ou atacam o problema errado ou propõem soluções que violam requisitos do enunciado.
I/O bound no InnoDB: Sintoma (Disco lido/escrito em excesso, CPU ociosa); Causa (Buffer pool subdimensionado, Baixa taxa de cache hit); Solução imediata (Aumentar innodb_buffer_pool_size, 70–80% da RAM disponível, Configurar no my.cnf); Soluções erradas (Desabilitar binlog + READ UNCOMMITTED, Migrar para MyISAM, Sharding imediato, Reduzir flush_log_at_trx_commit)
Alternativa A — ❌ Incorreta
Desabilitar o binary log reduz escritas em disco, é verdade, mas isso compromete a recuperação point-in-time e a replicação — e o enunciado exige "garantia de integridade transacional", que não depende do binlog, mas que seria prejudicada pela segunda parte da alternativa: mudar para READ UNCOMMITTED elimina locks e deadlocks? Não. Esse nível de isolamento permite leituras sujas (lê dados não confirmados) e não elimina locks de escrita — apenas relaxa o controle de leitura. É uma medida que viola a integridade dos dados e não resolve o problema de cache. O erro aqui é duplo: ataca o log (que não é a causa do I/O excessivo) e propõe um isolamento que compromete a consistência.
Alternativa B — ✅ Correta ⟵ GABARITO
Aumentar o innodb_buffer_pool_size é a ação mais imediata e eficaz para mitigar I/O excessivo em InnoDB. O buffer pool é o principal cache de dados e índices do engine; ao ampliá-lo, as páginas mais acessadas ficam na memória, reduzindo drasticamente as operações de leitura e escrita em disco. A alternativa está alinhada com a prática recomendada pela documentação oficial do MySQL e com o sintoma descrito (I/O bound com CPU ociosa). O parâmetro deve ser configurado no my.cnf e, idealmente, ocupar a maior parte da RAM disponível, respeitando a memória necessária para o SO e outros processos.
Alternativa C — ❌ Incorreta
Converter tabelas InnoDB para MyISAM é um retrocesso grave. MyISAM não suporta transações, nem foreign keys, nem recuperação crash-safe — exatamente o que o sistema exige ("garantia de integridade transacional"). Além disso, MyISAM não é o motor padrão do MySQL desde a versão 5.5 (o padrão é InnoDB) e seu cache de índices é menos eficiente para workloads de leitura intensa com escrita concorrente, pois usa table-level locking. A alternativa erra ao afirmar que MyISAM tem "cache de índices mais eficiente" e "desempenho superior em SELECT" — em cenários modernos, InnoDB com buffer pool adequado supera MyISAM em praticamente todos os aspectos.
Alternativa D — ❌ Incorreta
Sharding (fragmentação horizontal) é uma solução de escalabilidade distribuída, não uma resposta imediata para I/O excessivo causado por cache insuficiente. Implementar sharding é complexo, caro e não resolve o problema se a causa é o buffer pool pequeno — na verdade, distribuir dados em vários nós pode até piorar a latência se não houver planejamento. A alternativa afirma que é "a única capaz de resolver problemas de I/O excessivo, independentemente do uso da memória RAM", o que é falso: o ajuste de memória é a primeira linha de defesa e, na maioria dos casos, suficiente. Sharding é uma medida de longo prazo para escalabilidade, não uma ação imediata de tuning.
Alternativa E — ❌ Incorreta
Diminuir innodb_flush_log_at_trx_commit para 0 reduz a frequência de flush do log, o que melhora a performance de escrita, mas sacrifica a durabilidade: em caso de crash, transações confirmadas podem ser perdidas. Isso viola diretamente a exigência de "garantia de integridade transacional" do enunciado. Além disso, aumentar max_connections não resolve I/O bound — pelo contrário, mais conexões podem aumentar a contenção e o uso de memória, piorando o cenário. A alternativa mistura ajustes que não atacam a causa (cache) e que comprometem garantias críticas.
Gabarito: letra B — aumentar o innodb_buffer_pool_size é a ação imediata e correta para mitigar I/O excessivo em InnoDB, mantendo a integridade transacional.