Uma tela simples de consulta pode enviar centenas de comandos pequenos ao MySQL, um sistema pode exigir a escolha de uma ordem antes de cada busca, e uma tela pode ficar lenta em um computador remoto mesmo com poucos dados. Esses comportamentos dependem da forma como a aplicação lê os dados: um registro de cada vez, como nos antigos bancos de dados em arquivos, ou por conjuntos de linhas, como no SQL.
Dois modelos de acesso
No acesso por conjunto, a aplicação descreve o resultado que deseja, e o servidor decide como encontrá-lo. Um único SELECT pede as vendas de um dia, e o MySQL devolve o conjunto inteiro de uma vez.
No acesso por registro, a aplicação trabalha com um registro de cada vez. Ela escolhe uma ordem, procura uma posição nessa ordem e avança ou recua um registro por vez, sempre a partir de um registro atual. Esse modelo se chama ISAM, sigla em inglês de método de acesso sequencial indexado, e era a forma de trabalho dos bancos de dados em arquivos. Nesses bancos, cada tabela era um arquivo no disco, os índices ficavam em arquivos próprios, e o programa de cada estação lia e gravava esses arquivos direto na pasta compartilhada.
As operações da navegação
A leitura no acesso por registro se faz com poucas operações:
- Escolher a ordem: a aplicação indica por qual índice os registros serão percorridos, como a ordem de código ou a ordem de descrição.
- Posicionar: a aplicação procura uma chave na ordem escolhida, como o código 7891234567890, e o registro encontrado passa a ser o registro atual.
- Avançar e recuar: a aplicação passa para o registro seguinte ou para o anterior na mesma ordem.
- Ir ao início ou ao fim: a aplicação vai para o primeiro ou para o último registro da ordem.
Uma lista de produtos que mostra vinte linhas e permite rolar a tela funciona assim: a aplicação posiciona no primeiro produto da ordem e avança um registro de cada vez até preencher a tela. Para listar as vendas de um dia, a aplicação posiciona na primeira venda do dia, na ordem de data, e avança até encontrar uma venda de outro dia.
A navegação sobre um banco SQL
Muitos sistemas nasceram no modelo de acesso por registro e passaram a guardar os dados em um banco SQL sem reescrever as telas. Nesses sistemas, uma camada da aplicação converte cada operação de navegação em consultas. O pedido de avançar a partir do produto atual, na ordem de código, vira uma consulta parecida com esta:
SELECT * FROM produtos WHERE codigo > '7891234567890' ORDER BY codigo LIMIT 20;
A navegação precisa de uma ordem sem empates. Se dois produtos tivessem o mesmo código, a busca pelos códigos maiores que o código atual pularia o segundo deles. Por isso, esses sistemas acrescentam um desempate à ordem, normalmente um número que identifica cada registro de forma estável, e a ordem real passa a ser o código seguido desse número.
O efeito da rede
Cada consulta enviada ao servidor espera a ida do pedido e a volta da resposta pela rede. Esse tempo de ida e volta, chamado de latência, fica abaixo de um milissegundo na rede local e pode chegar a dezenas de milissegundos em uma VPN pela Internet. Uma tela que envia 500 consultas pequenas acumula menos de meio segundo de espera na rede local e cerca de vinte segundos em um caminho com 40 milissegundos de latência, mesmo que cada consulta leve muito pouco tempo no servidor.
Por isso, o acesso por registro é sensível à latência, mais do que à velocidade de transferência da conexão. Algumas aplicações reduzem esse efeito com a leitura em lotes. A camada busca várias linhas de uma vez e atende os próximos avanços com as linhas já recebidas.
O que aparece no servidor
No MySQL, o acesso por registro aparece como uma sequência de consultas curtas e parecidas, com ORDER BY e LIMIT, que se repetem com valores diferentes. O comando SHOW PROCESSLIST; mostra essas consultas passando rapidamente pelas conexões das estações.
Cada ordem usada na navegação depende de um índice com as mesmas colunas, na mesma sequência. Sem esse índice, cada consulta da navegação obriga o MySQL a examinar e ordenar a tabela inteira para devolver poucas linhas, e a lentidão se repete a cada avanço.
O que o modelo traz para o banco
Um sistema que navega registro por registro sobre um banco SQL costuma levar para as tabelas alguns elementos do modelo de origem:
- um número de registro, guardado em uma coluna própria, que identifica cada linha de forma estável e serve de desempate na navegação;
- a exclusão marcada, em que a aplicação marca a linha e uma rotina de manutenção a remove depois;
- colunas calculadas pela aplicação para atender ordens que o banco não monta sozinho, como uma descrição em letras maiúsculas;
- uma tabela de controle que descreve as ordens de cada tabela e os índices correspondentes.
Esses elementos são mantidos pela aplicação, e uma alteração feita direto no banco não passa por eles.
No suporte
Quando uma tela fica lenta apenas em computadores remotos, a quantidade de consultas por operação é uma suspeita forte. A comparação do tempo da mesma operação na rede local e no caminho remoto, junto com a lista de consultas enviadas pela aplicação, separa a demora da rede da demora do banco.
Para guardar
- No acesso por conjunto, a consulta descreve o resultado, e o servidor decide como encontrá-lo.
- No acesso por registro, a aplicação escolhe uma ordem, posiciona em uma chave e avança um registro de cada vez.
- Sobre um banco SQL, cada operação de navegação vira consultas com ORDER BY e LIMIT.
- A navegação precisa de uma ordem sem empates, e por isso usa um número de registro como desempate.
- O acesso por registro é sensível à latência da rede, porque envia muitos pedidos pequenos.
- Cada ordem de navegação precisa de um índice com as mesmas colunas.
Uma tela de consulta abre rapidamente no balcão 01, mas leva quase meio minuto em um computador da matriz que acessa o banco da loja pela VPN. O banco é o mesmo. Qual é a explicação provável?
A tela envia muitas consultas pequenas, e cada uma espera a ida e a volta pela rede. Na rede local, essa espera é desprezível. Na VPN, com 40 milissegundos por consulta, 500 consultas somam cerca de vinte segundos. A demora vem da quantidade de pedidos multiplicada pela latência, e não do banco.
Se os dados já estão em um banco SQL, por que a aplicação ainda escolhe uma ordem e trabalha com um registro atual?
Porque o código das telas conserva o modelo de acesso por registro. Uma camada da aplicação converte cada operação de navegação em consultas SQL. A troca do lugar em que os dados ficam guardados não muda, sozinha, o modelo usado pelo código.