Erros comuns do MySQL e como corrigi-los rapidamente

O MySQL é uma pedra angular de muitas aplicações web, valorizado por sua confiabilidade e desempenho. No entanto, à medida que os bancos de dados escalam e o tráfego aumenta, os administradores inevitavelmente encontram obstáculos operacionais. 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 serve como um manual prático de solução de problemas para problemas frequentes do MySQL. Cobriremos problemas prevalentes como execução lenta de consultas, deadlocks de transação, falhas de replicação e corrupção de dados. Ao aprender a interpretar logs de erro e aplicar soluções estabelecidas, você pode minimizar o tempo de inatividade e garantir que seu ambiente de banco de dados permaneça robusto.

Identificando e Diagnosticando Erros do MySQL

Antes de aplicar correções, a identificação precisa é fundamental. As principais fontes de informação de diagnóstico do MySQL são o Log de Erros do MySQL e o Log de Consultas Lentas (Slow Query Log). Verificar estes 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 de acordo com o sistema operacional e a configuração, mas geralmente é encontrada 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 é a sua próxima parada. 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 Erros 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 a maior causa de drenagem de desempenho. Elas geralmente resultam 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 large_table WHERE column_a = 'value';

Procure por type: ALL (varredura completa da tabela) ou linhas examinadas em excesso.

Correções Rápidas

Adicionar Índices Ausentes: Se o EXPLAIN mostrar uma varredura completa em uma coluna frequentemente filtrada, crie um índice nessa coluna: CREATE INDEX idx_column_a ON large_table (column_a);
Reescrever Consultas: Evite SELECT * em código de produção. Use JOINs com critério 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 table_name;.

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 que referenciem LATEST DETECTED DEADLOCK. Você também pode verificar o status do InnoDB:

SHOW ENGINE INNODB STATUS;

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

Correções Rápidas

Encurtar Transações: Mantenha as transações o mais breves possível. Faça commit ou rollback 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 de Nível de Linha: Garanta que você está usando cláusulas WHERE apropriadas nas declarações UPDATE e DELETE para que o InnoDB possa bloquear apenas as linhas necessárias, e não tabelas inteiras (embora o InnoDB use bloqueio de nível de linha por padrão para tabelas transacionais).

3. Atraso ou Falha na Replicação

Em configurações mestre-escravo (primário-réplica), o atraso de replicação ocorre quando a réplica fica para trás da mestra, resultando em leituras desatualizadas. Falha significa que a réplica para completamente de aplicar eventos.

Diagnóstico

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

SHOW SLAVE STATUS\G

Campos chave para examinar:

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

Correções Rápidas

Resolver Erros da Thread SQL: Se Slave_SQL_Running for No, revise o campo Last_SQL_Error. Se o erro for transitório (ex: inserção de chave duplicada), talvez seja necessário pular o evento problemático: SET GLOBAL sql_slave_skip_counter = 1; START SLAVE; (Use com cautela!)
Aumentar Recursos da Réplica: Se o atraso for consistente sob forte carga de gravação, a réplica pode precisar de mais CPU ou I/O de disco mais rápido para processar os eventos de log binário com rapidez suficiente.
Ressincronizar: Se o atraso for grave ou a réplica estiver quebrada, pare a replicação, certifique-se de que a réplica esteja apontando para a posição correta do log binário da mestra e reinicie.

4. Erros de Corrupção de Dados

A corrupção de dados, embora rara em configurações InnoDB modernas, pode se manifestar como incapacidade de iniciar o servidor, erros de checksum ou resultados de consulta estranhos. 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 na inicialização no log de erros, frequentemente referenciando tablespaces ou páginas específicas falhando em um teste de checksum.

Correções Rápidas

Executar Verificação/Reparo de Tabela (MyISAM): Para tabelas MyISAM, use CHECK TABLE table_name; seguido por REPAIR TABLE table_name;.
Modo de Recuperação do InnoDB: Se o InnoDB falhar ao iniciar, você pode temporariamente iniciá-lo no modo de recuperação para despejar dados:
ini [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 uma maior degradação dos dados se as gravações forem tentadas.
Restaurar a partir do Backup: A solução mais segura para corrupção grave é restaurar todo o banco de dados a partir do último backup conhecido bom.

Prática Recomendada: Monitoramento Proativo

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

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

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