Erros Comuns no MySQL e Como Corrigi-los Rapidamente

Os erros do MySQL geralmente exigem uma leitura rápida inicial: verifique o log de erros, identifique a consulta ou thread com falha e evite suposições baseadas apenas no sintoma da aplicação. Entender como diagnosticar e resolver rapidamente erros comuns — desde gargalos de desempenho até falhas críticas de serviço — é essencial para manter a alta disponibilidade.

Este guia aborda falhas comuns do MySQL que você pode triar rapidamente: consultas lentas, deadlocks, atraso de replicação e avisos de corrupção.

Identificando e Diagnosticando Erros no MySQL

Antes de aplicar correções, a identificação precisa é fundamental. As principais fontes de informações de diagnóstico do MySQL são o Log de Erros do MySQL e o Log de Consultas Lentas. Verificá-los primeiro é a maneira mais eficaz de identificar a causa raiz de um problema.

Verificando o Log de Erros do MySQL

O log de erros registra eventos críticos do servidor, informações de inicialização/desligamento e erros graves. Sua localização varia conforme o sistema operacional e a configuração, mas geralmente é encontrado no diretório de dados.

Dica: Use comandos como SHOW VARIABLES LIKE 'log_error'; para encontrar o caminho exato se não tiver certeza.

Utilizando o Log de Consultas Lentas

Se o desempenho degradar sem mensagens de erro explícitas, o Log de Consultas Lentas é o próximo passo. Ele captura consultas que excedem um tempo de execução predefinido.

Para ativá-lo (se ainda não estiver ativo), você deve definir estas variáveis no seu arquivo de configuração (my.cnf ou my.ini) e reiniciar o servidor:

[mysqld]
slow_query_log = 1
long_query_time = 2  # Registra consultas que demoram mais de 2 segundos
slow_query_log_file = /var/log/mysql/mysql-slow.log

Cenários de Erro Comuns e Correções Imediatas

Aqui estão quatro dos desafios operacionais mais frequentes encontrados em ambientes MySQL e etapas acionáveis para resolvê-los.

1. Desempenho Lento de Consultas

Consultas lentas são o dreno de desempenho mais comum. Geralmente decorrem de índices ausentes, estruturas de consulta ineficientes ou design de banco de dados inadequado.

Diagnóstico

Analise o log de consultas lentas. Para uma consulta lenta específica, use o comando EXPLAIN para ver como o MySQL a executa:

EXPLAIN SELECT * FROM tabela_grande WHERE coluna_a = 'valor';

Procure por type: ALL (varredura completa da tabela) ou número excessivo de linhas examinadas.

Correções Rápidas

Adicionar Índices Ausentes: Se EXPLAIN mostrar uma varredura completa em uma coluna frequentemente filtrada, crie um índice nessa coluna: CREATE INDEX idx_coluna_a ON tabela_grande (coluna_a);
Reescrever Consultas: Evite SELECT * em código de produção. Use JOINs com moderação e garanta que as cláusulas WHERE usem colunas indexadas.
Analisar Estatísticas da Tabela: Às vezes, estatísticas desatualizadas confundem o otimizador. Execute ANALYZE TABLE nome_da_tabela;.

2. Deadlocks de Transação

Um deadlock ocorre quando duas ou mais transações estão esperando por bloqueios mantidos pela outra, resultando em um impasse. O MySQL (usando InnoDB) geralmente detecta e resolve isso automaticamente revertendo uma transação.

Diagnóstico

Verifique o log de erros em busca de mensagens referentes a LATEST DETECTED DEADLOCK. Você também pode verificar o status do InnoDB:

SHOW ENGINE INNODB STATUS;

Procure na seção TRANSACTIONS pelo gráfico detalhado do deadlock, que mostra quais transações estavam envolvidas e quais instruções causaram a espera.

Correções Rápidas

Encurtar Transações: Mantenha as transações o mais breves possível. Confirme ou reverta rapidamente.
Ordem de Acesso Consistente: Garanta que todo o código da aplicação acesse tabelas e linhas na mesma ordem definida. Se a Transação A bloqueia a Tabela X e depois a Tabela Y, a Transação B também deve bloquear X e depois Y.
Usar Bloqueio em Nível de Linha: Certifique-se de usar cláusulas WHERE apropriadas nas instruções UPDATE e DELETE para que o InnoDB possa bloquear apenas as linhas necessárias, não tabelas inteiras (embora o InnoDB use bloqueio em nível de linha por padrão para tabelas transacionais).

3. Atraso ou Falha de Replicação

Em configurações de fonte-réplica, o atraso de replicação ocorre quando a réplica fica atrás da fonte, levando a leituras desatualizadas. Comandos e campos mais antigos do MySQL ainda usam a terminologia master e slave, então você pode ver ambos os nomes em produção.

Diagnóstico

Verifique o status da réplica usando as threads IO e SQL:

SHOW REPLICA STATUS\G
-- Em versões mais antigas do MySQL: SHOW SLAVE STATUS\G

Campos principais a examinar:

Replica_IO_Running ou Slave_IO_Running: Deve ser Yes.
Replica_SQL_Running ou Slave_SQL_Running: Deve ser Yes.
Seconds_Behind_Source ou Seconds_Behind_Master: Indica o atraso em segundos. Se este valor estiver aumentando, a réplica está ficando para trás.

Correções Rápidas

Resolver Erros da Thread SQL: Se o aplicador SQL estiver parado, revise o último erro SQL. Pular um evento com sql_slave_skip_counter ou comandos de replicação mais recentes pode causar divergência de dados, então use-o somente depois de entender a transação com falha e ter um plano para reconciliar os dados.
Aumentar Recursos da Réplica: Se o atraso for consistente sob carga pesada de gravação, a réplica pode precisar de mais CPU ou I/O de disco mais rápido para processar eventos de log binário com rapidez suficiente.
Ressincronizar: Se o atraso for grave ou a réplica estiver quebrada, pare a replicação, garanta que a réplica esteja apontando para a posição correta do log binário da fonte e reinicie.

4. Erros de Corrupção de Dados

A corrupção de dados, embora rara com configurações modernas do InnoDB, pode se manifestar como incapacidade de iniciar o servidor, erros de checksum ou resultados estranhos de consultas. A corrupção geralmente aponta para falha de hardware (disco/memória) ou desligamentos inadequados.

Diagnóstico

A corrupção geralmente é imediatamente aparente por meio de mensagens de falha de inicialização no log de erros, frequentemente referenciando tablespaces ou páginas específicas que falham em um teste de checksum.

Correções Rápidas

Executar Verificação/Reparo de Tabela (MyISAM): Para tabelas MyISAM, use CHECK TABLE nome_da_tabela; seguido por REPAIR TABLE nome_da_tabela;.
Modo de Recuperação do InnoDB: Se o InnoDB falhar ao iniciar, você pode iniciá-lo temporariamente no modo de recuperação para despejar dados:
```
[mysqld]
innodb_force_recovery = 1
```
Inicie o servidor, despeje imediatamente todos os dados críticos usando mysqldump, desligue, remova os arquivos de dados corrompidos e reinicie sem a flag de recuperação.

Aviso: innodb_force_recovery nunca deve ser usado permanentemente. Ele ignora verificações críticas e pode levar a mais degradação de dados se gravações forem tentadas.
Restaurar a partir de Backup: A resolução mais segura para corrupção grave é restaurar todo o banco de dados a partir do último backup bom conhecido.

Conclusão

Corrija problemas do MySQL com base em evidências, não em suposições. O log de erros, o log de consultas lentas, EXPLAIN, o status do InnoDB e o status de replicação geralmente mostram o próximo passo. Mantenha backups testados antes de tocar em recuperação de corrupção ou comandos de salto de replicação.

Melhor Prática: Monitoramento Proativo

A correção mais rápida geralmente é a prevenção. Implemente ferramentas de monitoramento abrangentes (como Prometheus/Grafana, Percona Monitoring and Management (PMM) ou ferramentas do provedor de nuvem) para acompanhar métricas-chave:

Número de conexões e taxa de acerto do cache de threads.
Uso e taxa de acerto do buffer pool do InnoDB.
Atraso de replicação (Seconds_Behind_Master).
Utilização de I/O de disco.

Alertas baseados nessas métricas permitem que você aborde consultas lentas ou problemas de replicação antes que eles se transformem em falhas críticas.