Fluxo de diagnóstico

Diante de uma falha no banco, a vontade de agir logo leva a reparos desnecessários, que às vezes destroem a evidência ou pioram o dano. O diagnóstico transforma o sintoma em uma decisão sustentada por observações, em uma sequência que vai do mais simples ao mais pesado:

1. entender o sintoma;
2. localizar a camada do problema;
3. preservar o estado antes de qualquer intervenção;
4. identificar o servidor, a versão, o engine e as medidas da tabela;
5. observar o servidor durante o sintoma;
6. verificar a estrutura física;
7. conferir a lógica da aplicação e o caminho da consulta;
8. decidir a intervenção;
9. validar o resultado.

Entender o sintoma

O ponto de partida é a descrição precisa: a mensagem completa, a tela, o horário, as estações afetadas e o que mudou antes. Um erro em todas as estações aponta para o servidor ou para a rede, e um erro em uma só estação aponta para a configuração ou para o caminho dessa estação. Uma busca que não encontra um registro é diferente de uma busca que demora, e as duas são diferentes de uma mensagem de erro.

Localizar a camada

As mensagens de erro já indicam a camada. Os erros de conexão, como os de servidor inalcançável e de acesso negado, apontam para a rede, para o serviço ou para a conta. Os erros de permissão mostram que a conexão funcionou. As mensagens de tabela danificada e os erros de leitura apontam para o engine e para os arquivos. Uma busca sem erro e sem resultado aponta para a lógica da aplicação. No próprio servidor, o comando mysqladmin ping confirma se o serviço responde.

Preservar

Quando a investigação pode levar a uma intervenção, a preservação vem antes:

• o log de erros do MySQL e o registro de erros da aplicação;
• a cópia dos arquivos ou a exportação das tabelas envolvidas, conforme o engine e o estado;
• a tabela de controle das ordens, quando a intervenção pode atingir os índices.

Identificar o servidor e a tabela

• SELECT VERSION(), @@hostname, DATABASE();: confirma o servidor, a versão e o banco;
• SHOW CREATE TABLE vendas;: mostra a definição, os índices, o engine e o próximo valor do contador;
• SELECT COUNT(*), MAX(id) FROM vendas;: guarda a contagem exata e o maior identificador.

Essas medidas servem de referência para a validação. Se a tabela não pode ser lida, a medida fica registrada como indisponível.

Observar durante o sintoma

• SHOW FULL PROCESSLIST;: mostra se as conexões estão trabalhando ou esperando;
• SHOW ENGINE INNODB STATUS;: mostra, nas tabelas InnoDB, as transações abertas, as esperas por bloqueio e o último deadlock.

Nas tabelas MyISAM, as esperas aparecem na própria lista de conexões, no estado Locked, no MySQL 5.1, ou Waiting for table level lock, nas versões seguintes. Em um servidor sem o InnoDB, o segundo comando falha com o erro 1286, de engine desconhecido.

Uma consulta que espera outra conexão não melhora com nenhum reparo. Nesse caso, o caminho é identificar a conexão que bloqueia, a origem dela e o trabalho pendente.

Verificar a estrutura física

• CHECK TABLE vendas;: procura os defeitos físicos que o engine consegue verificar.

A verificação de uma tabela grande acontece em uma janela de manutenção. No MyISAM, ela bloqueia as gravações, e, no InnoDB, uma página danificada pode encerrar o servidor. O resultado OK não prova a integridade completa, nem a lógica dos dados.

Conferir a lógica e o caminho da consulta

Quando a estrutura física está íntegra e o problema continua, as hipóteses lógicas vêm primeiro: o SQL que a aplicação enviou, a marca de exclusão, a condição da ordem, as colunas derivadas e a correspondência entre a tabela de controle e os índices. O plano da consulta mostra se a demora vem de um caminho ruim:

• EXPLAIN SELECT * FROM vendas WHERE data_venda >= '2026-10-01' AND data_venda < '2026-11-01';

Uma comparação ajuda a encontrar um índice em desacordo com os dados. A mesma contagem, feita uma vez pelo índice e outra sem ele, deveria dar o mesmo número:

• SELECT COUNT(*) FROM vendas FORCE INDEX (idx_vendas_data) WHERE data_venda >= '2000-01-01';
• SELECT COUNT(*) FROM vendas IGNORE INDEX (idx_vendas_data) WHERE data_venda >= '2000-01-01';

A comparação só vale com os dados parados, sem gravações entre as duas contagens, e com o plano de cada consulta conferido. Uma diferença que se repete nessas condições indica um índice em desacordo com os dados.

Decidir

• Estatísticas desatualizadas: o ANALYZE TABLE atualiza as estatísticas.
• Espera por bloqueio: a identificação da conexão que bloqueia e a decisão sobre a transação ou o comando dela.
• Índice danificado em uma tabela InnoDB legível: a reconstrução da tabela.
• Dados ilegíveis em uma tabela InnoDB: a exportação do que pode ser lido ou a restauração de uma cópia.
• Índice danificado em uma tabela MyISAM: o reparo com a opção QUICK.
• Dados danificados em uma tabela MyISAM: o reparo no modo padrão ou com a opção EXTENDED, conforme a mensagem.
• Arquivo de índices ausente em uma tabela MyISAM: o reparo com a opção USE_FRM e a recuperação do contador.
• Ordem, marca ou coluna derivada incoerente: a rotina da aplicação.
• Evidência insuficiente: a investigação continua, sem intervenção.

Validar

A validação repete as medidas da identificação, com as mesmas consultas e condições, e confere o contador. Depois vêm os testes na aplicação: a busca que falhava, a navegação e os relatórios afetados. Um comando concluído com sucesso não substitui essa validação.