As quatro camadas do acesso aos dados

Uma busca pode falhar porque a tela aplicou um filtro, porque o sistema montou uma consulta errada, porque o MySQL recusou a consulta ou porque os arquivos da tabela estão danificados. Separar essas partes indica onde procurar as evidências antes de decidir por qualquer manutenção.

Da tela ao armazenamento

Uma camada é uma parte do trabalho com responsabilidade própria. O acesso aos dados pode ser organizado em quatro camadas:

• Aplicação: o sistema da loja, com as telas, as regras de negócio e os filtros. É a aplicação que decide o que precisa ser consultado ou gravado.
• Camada de acesso a dados: a parte do sistema que transforma os pedidos da aplicação em comandos SQL e os envia ao servidor. Essa parte pode ser uma biblioteca pronta, chamada de driver ou conector, ou um componente próprio do sistema.
• Servidor MySQL: recebe o SQL, confere o usuário e as permissões, escolhe como executar a consulta e mantém as definições das tabelas e dos índices.
• Engine e arquivos: o mecanismo de armazenamento, chamado de engine, organiza as linhas e os índices nos arquivos do servidor. O InnoDB é o engine padrão a partir do MySQL 5.5, e o MyISAM era o padrão nas versões anteriores, como a 5.1. Existem outros engines, para usos específicos, mas esses dois são os mais comuns.

Onde cada camada funciona

Quando o caixa 01, no endereço 192.168.1.20, procura uma venda, a aplicação pede a busca à camada de acesso a dados. Essa camada monta o SQL e o envia pela rede à porta 3306 do servidor da loja, no endereço 192.168.1.10. O MySQL recebe a consulta e pede ao engine os dados necessários. O engine lê os arquivos e a memória do servidor, e a resposta percorre o caminho inverso até a tela.

A aplicação e a camada de acesso a dados rodam na estação. O MySQL e o engine rodam no servidor do banco. A rede fica entre essas partes. A rede não é uma quinta camada desse mapa, mas uma falha de comunicação impede a estação de alcançar o servidor.

As evidências de cada camada

Cada camada deixa um tipo diferente de evidência:

• Aplicação: as mensagens da tela e os registros do sistema mostram as regras de negócio, os filtros e as validações. Uma recusa de cadastro pode vir de uma regra do sistema, com o banco funcionando normalmente.
• Camada de acesso a dados: muitos sistemas conseguem registrar o SQL enviado ao servidor e os erros devolvidos por ele. O SQL registrado mostra exatamente o que foi pedido, inclusive quando uma consulta foi aceita, mas buscou algo diferente do esperado.
• Servidor MySQL: o log de erros registra os problemas do serviço. No Windows, esse arquivo costuma ficar na pasta de dados do MySQL, com a extensão err.
• Engine e arquivos: o estado da tabela e as verificações de integridade mostram problemas físicos, como arquivos danificados.

No servidor, alguns comandos reúnem essas evidências:

• SHOW CREATE TABLE vendas;: mostra a definição da tabela, com as colunas, os índices e o engine;
• SHOW INDEX FROM vendas;: mostra os índices da tabela e a ordem das colunas de cada um;
• EXPLAIN, escrito antes de um SELECT: mostra o caminho que o MySQL escolheu para executar a consulta;
• SHOW PROCESSLIST;: mostra as conexões abertas e o que cada uma está executando ou esperando;
• SHOW TABLE STATUS LIKE 'vendas';: mostra o estado e as características da tabela;
• CHECK TABLE vendas;: procura problemas físicos na tabela.

O sintoma orienta, mas não confirma

Uma consulta lenta pode estar sem um índice adequado, esperando outra conexão ou disputando os recursos do servidor. Uma queda de energia ou um erro de disco pode danificar os arquivos. O sintoma indica onde começar a coleta de evidências, mas não confirma a causa sozinho.