Consultoria MySQL: o guia técnico para decidir quando — e com quem — contratar.

Uma SELECT que rodava em 200ms começa a levar 4 segundos conforme a tabela cresce. Uma réplica que estava em sincronia passa a acumular minutos de replication lag durante o horário de pico — e o relatório do dia seguinte mostra dados desatualizados. O time aumenta a instância, troca por uma classe maior na AWS, paga mais — e o problema volta na semana seguinte.

MySQL é o RDBMS open-source mais usado do mundo. E, justamente por isso, a maior parte dos problemas que aparecem em produção tem causa raiz conhecida e documentável: índice composto errado, isolation level mal escolhido, innodb_buffer_pool_size dimensionado pela metade do que deveria, replicação single-threaded em versões antigas. Não é mistério — é falta de profundidade técnica em quem operou o ambiente.

Este artigo é um guia direto para quem está pesquisando antes de contratar consultoria MySQL: quais sinais indicam que faz sentido buscar ajuda externa, o que uma consultoria séria realmente faz no ambiente, e como diferenciar quem entende do produto de quem só sabe rodar comandos.

Subir a instância para um tier maior costuma ser o primeiro reflexo. Funciona por algumas semanas, até o volume crescer mais e o teto novo voltar a ser atingido. A maioria dos casos abaixo não se resolve com hardware — se resolve com diagnóstico:

1. Slow queries que pioram à medida que a tabela cresce

Quando o tempo de resposta de uma query cresce de forma não-linear com o volume da tabela, a causa quase sempre é falta de índice composto correto, uso de função em coluna no WHERE (impedindo o otimizador de usar o índice), ou um ORDER BY que força ordenação em memória/disco. EXPLAIN mostra isso em segundos para quem sabe ler o plano.

2. Deadlocks recorrentes em horários de pico

Deadlock não é "bug do MySQL" — é a aplicação adquirindo locks em ordens diferentes entre transações concorrentes, ou usando isolation level mais alto do que o necessário (gerando gap locks desnecessários em InnoDB). A solução passa por análise do SHOW ENGINE INNODB STATUS e ajuste na ordem de acesso dentro das transações da aplicação.

3. Replication lag crescente

Em versões antigas de MySQL a replicação é single-threaded por padrão, e uma transação grande na primária trava a aplicação na réplica por minutos. Em versões modernas, replicação paralela LOGICAL_CLOCK com binlog_transaction_dependency_tracking = WRITESET resolve a maior parte dos casos — desde que o ambiente esteja configurado para isso.

4. innodb_buffer_pool_size mal dimensionado

O buffer pool é o cache que mantém páginas de dados e índices em RAM. Subdimensionado, o MySQL passa a ler do disco a cada query, e o I/O vira gargalo mesmo em SSD NVMe. A regra prática é 60-70% da RAM em servidores dedicados — mas o número certo depende do innodb_buffer_pool_reads versus innodb_buffer_pool_read_requests no ambiente real.

5. Falta de estratégia em tabelas que passaram de centenas de milhões de linhas

A partir de um certo volume, manutenção, backup, índice e até ALTER TABLE simples deixam de caber numa janela operacional. Particionamento horizontal por RANGE (datas) ou HASH (sharding lógico) pode ser a solução — ou pode ser complexidade pura, dependendo do padrão de acesso. Tomar essa decisão sem dados é caro.

6. Backup que nunca foi testado em um restore real

"Temos backup" não é a resposta para a pergunta certa. A pergunta é: quanto tempo leva para restaurar, e que volume de dados aceitamos perder? RTO e RPO precisam estar documentados, medidos e validados em exercício real — não estimados. Em ambientes que nunca rodaram um restore de ponta a ponta, geralmente é descoberto em emergência que o backup estava incompleto ou levaria 18 horas para voltar.

7. Picos de CPU e I/O sem explicação

Quando o monitoramento mostra apenas métricas de infraestrutura (CPU, memória, disco) e nada sobre comportamento do banco — quais queries rodaram, com qual frequência, em qual padrão de acesso — qualquer investigação vira adivinhação. Monitoramento sério inclui performance_schema, sys schema, slow query log com long_query_time ajustado, e correlação com eventos da aplicação.

"Hardware compra tempo. Diagnóstico compra a solução."

Não é "olhar o ambiente e dar opinião". Uma consultoria MySQL séria segue um roteiro técnico documentado e entrega evidências em cada bloco — não apenas conclusões.

Auditoria de configuração (my.cnf / parameter groups)

Os parâmetros centrais são poucos, mas cada um carrega trade-off real. innodb_buffer_pool_size define quanto do dataset fica em RAM — subdimensionado vira gargalo de I/O, superdimensionado em servidor compartilhado causa swap. innodb_log_file_size dimensiona o redo log: pequeno força flushes frequentes e prejudica throughput de writes, grande aumenta o tempo de crash recovery. max_connections precisa ser pensado em conjunto com pool da aplicação para não explodir em memória. innodb_flush_log_at_trx_commit é o trade-off mais direto entre durabilidade e performance: 1 é ACID estrito (cada commit vai para disco), 2 deixa o SO bufferizar (perda potencial de 1s em crash de host), 0 é mais rápido mas pode perder até 1s mesmo em crash do MySQL — escolha defensável só conhecendo o RPO aceito pelo negócio.

Análise de queries via EXPLAIN e slow query log

EXPLAIN mostra o plano de execução: qual índice o otimizador escolheu, quantas linhas ele estima percorrer, se está fazendo full table scan, se está usando filesort ou criando tabela temporária em disco (Using temporary; Using filesort). Um plano problemático típico:

type: ALL = full table scan. possible_keys: NULL = nenhum índice utilizável. Using filesort = ordenação em disco. A função YEAR() aplicada na coluna impediu o otimizador de usar o índice em created_at. Solução: reescrever para created_at >= '2025-01-01' AND created_at < '2026-01-01' — mesmo resultado, plano com type: range usando o índice. Quem nunca leu um plano de execução não vê esse tipo de coisa.

Estratégia de índices e particionamento

Índice simples cobre uma coluna; útil para igualdade em coluna única. Índice composto cobre múltiplas colunas em ordem definida — só é usado se o filtro inclui o prefixo à esquerda. Covering index é o índice composto que inclui todas as colunas que a query precisa, eliminando o lookup na tabela. Em queries quentes, covering index reduz o I/O em ordem de grandeza.

Particionamento horizontal (RANGE por data, HASH por chave) ajuda quando as queries sempre filtram pela chave de partição — aí o otimizador faz partition pruning e ignora as outras partições. Quando o padrão de acesso não usa a chave, particionamento só adiciona overhead. Em bancos com retenção temporal forte, PARTITION BY RANGE em coluna de data transforma um DELETE de milhões de linhas em ALTER TABLE ... DROP PARTITION instantâneo.

Alta disponibilidade e replicação

Replicação assíncrona é o padrão e o mais rápido — a primária confirma o commit sem esperar a réplica, com risco de perda em failover. Semi-síncrona (rpl_semi_sync_master_enabled) exige que pelo menos uma réplica confirme o recebimento do binlog antes do commit voltar para a aplicação — RPO próximo de zero a um custo de latência por commit. Group Replication entrega um cluster multi-primary com consenso, e MySQL Router roteia escritas para a primária e leituras para as réplicas automaticamente — desde que a aplicação use as portas corretas.

Para times que estão diagnosticando lentidão em geral — não só MySQL — vale ler também o guia de gargalos de performance em banco de dados, que cobre o método de diagnóstico antes de mexer em parâmetro nenhum.

São produtos diferentes para necessidades diferentes — e contratar o errado é caro nos dois sentidos.

O Health Check de banco de dados é um diagnóstico tático fechado em até 48h: auditoria de configuração, análise das top queries pelo slow query log, validação de backup e replicação, e relatório com plano de ação priorizado. Serve para estabilizar um problema agudo ou ter uma fotografia técnica honesta do ambiente antes de tomar uma decisão maior (migração, troca de versão, contratação de DBA).

O DBA Remoto é sustentação contínua: monitoramento 24/7, NOC com SLA por severidade, abertura e tratamento de incidente, tuning recorrente, gestão de backup e DR, e atuação proativa antes de o problema chegar no usuário final. É o que evita que o problema diagnosticado no Health Check volte daqui a três meses, com o dobro do volume de dados.

A maior parte dos contratos de consultoria que dão errado erra na escolha — não na execução. Os padrões mais frequentes:

Confundir "saber rodar comandos" com profundidade real. Rodar SHOW PROCESSLIST e matar uma sessão travada resolve o sintoma. Entender por que aquela sessão travou — e mudar a configuração ou a query para que não trave de novo — exige profundidade em engine internals: como o InnoDB faz locking, quando promove gap lock, como o purge thread limpa undo log. Sem isso, o ciclo de "matar sessão travada" se repete eternamente.

Contratar quem não conhece engine internals. InnoDB e MyISAM são engines com comportamento radicalmente diferente em locking, transação e crash recovery. Quem trata os dois como "a mesma coisa, só muda o nome" vai tomar decisões erradas em ambos.

Ausência de SLA com penalidade real. "Atendimento 24/7" sem penalidade contratual por descumprimento é discurso comercial. SLA sério especifica tempo de resposta por severidade, multa por descumprimento e processo de escalonamento documentado.

Freelancers operando ambientes críticos sem auditoria. Acesso a banco de produção precisa de trilha de auditoria: quem acessou, quando, o que executou. Operação a partir de notebook pessoal em rede doméstica, sem segregação física nem auditoria, é risco de compliance — e, em ambientes regulados (LGPD, PCI, SOX), é não-conformidade direta.

Se o seu ambiente é SQL Server ou PostgreSQL, os sinais são parecidos — vale ver também o guia de consultoria SQL Server e o de consultoria PostgreSQL, que aplicam o mesmo método de diagnóstico a esses dois RDBMSs.

A HTI Tecnologia é "The Database Company" desde 1990 — mais de 35 anos sustentando bancos de dados críticos no Brasil. No caso específico de MySQL, três fatos sustentam o nível técnico do atendimento:

DBAs que colaboraram no código-fonte do próprio MySQL. Diagnóstico de comportamento de engine não vem de manual — vem de ter lido o código que executa aquele comportamento.

Duas vezes Authorized MySQL Education Center (AMEC) pela Oracle University. Única empresa no Brasil com essa credencial — e o que isso significa na prática é que a equipe é avaliada e mantida pelo próprio fornecedor do produto.

Mais de 1.000 DBAs formados em treinamentos oficiais. Boa parte do mercado brasileiro de DBA MySQL passou por uma sala de aula da HTI. Quem treina, conhece em profundidade.

Operacionalmente, todo o atendimento crítico ocorre a partir de sala física controlada com acesso biométrico, NDA padrão antes de qualquer acesso e trilha de auditoria por operador.

Consultoria MySQL bem feita não é mística — é método. Diagnóstico antes de mudar parâmetro. Evidência (plano de execução, slow log, métrica de buffer pool) antes de conclusão. Configuração ajustada à carga real, e não copiada de um post genérico. Sustentação contínua no que precisa ficar sob observação 24/7, Health Check pontual no que cabe em uma fotografia de 48h.

Se algum dos sinais descritos no início deste artigo descreve o seu ambiente, faz sentido conversar com um DBA Senior antes de aumentar instância de novo.