Otimização de Query em MySQL Reduz Tempo de Execução de Horas para Milissegundos em Tabela Bilionária

A notícia destaca um cenário familiar para muitos desenvolvedores: uma query crítica que, devido à escala dos dados (mais de 3,2 bilhões de linhas em uma tabela MySQL), levava impressionantes 1 hora e 43 minutos para ser concluída. O problema se dividia em dois pontos. Primeiro, um "desperdício lógico": o otimizador do MySQL falhou em aplicar um filtro de `chain_id` (que restringia a busca a uma cadeia de lojas específica) cedo o suficiente. Ele calculou 6,57 milhões de registros em uma tabela derivada, apenas para descartar a grande maioria depois, mantendo apenas 552.

Segundo, houve um "desajuste físico" na forma como o índice era usado. O índice `store_supplier_counted_at` começava com `store_id`, mas a parte lenta da query tentava filtrar por `supplier_id`. Pela regra do prefixo-mais-à-esquerda, isso impediu o uso eficiente do índice, forçando um "skip scan" que varreu 491 milhões de entradas. A solução foi reescrever a query para primeiro filtrar o conjunto menor de dados e, então, computar o `MAX(counted_at)` para essas lojas já restritas, culminando em uma subquery correlacionada. Este ajuste reduziu a varredura para cerca de 38 mil entradas de índice e o tempo de execução para apenas 40 milissegundos, sem alterar o esquema do banco de dados. Um exemplo clássico de que o entendimento profundo do plano de execução é fundamental.

Esta notícia sobre a otimização de uma query no MySQL aprofunda discussões anteriores do CEVIU. Em nossa matéria de 24 de agosto de 2026, "Otimização de Performance SQL: Estratégias para Índices Eficientes que Reduzem Tempos de Resposta", abordamos a importância da análise de padrões de consulta e a regra do prefixo-mais-à-esquerda para índices compostos. A nova matéria traz um estudo de caso real, transformando esses conceitos em um exemplo prático e mensurável.

Ela demonstra de forma contundente o impacto de como um otimizador de banco de dados pode interpretar uma query e como a intervenção manual, guiada pela compreensão do plano de execução (usando `EXPLAIN ANALYZE`), pode corrigir falhas do otimizador. O que antes era uma série de princípios para projetar índices e consultas eficientes, agora ganha um cenário concreto onde a aplicação dessas estratégias levou a uma melhoria de performance da ordem de 150 milhões de vezes, evitando alterações caras no esquema de um banco de dados gigantesco.

Este caso prático em MySQL é um lembrete valioso para qualquer profissional de desenvolvimento que lida com bancos de dados de grande escala. A performance de queries não é um problema exclusivo de sistemas legados; em infraestruturas modernas, o volume de dados pode expor gargalos inesperados. Entender como o banco de dados executa seu SQL, e não apenas o que o SQL faz, é crucial para a estabilidade e eficiência de qualquer aplicação.

A capacidade de diagnosticar e otimizar queries lentas, muitas vezes sem a necessidade de alterações caras de esquema ou infraestrutura, é uma habilidade fundamental. Isso impacta diretamente a experiência do usuário, a agilidade do desenvolvimento e a sustentabilidade de custos de sistemas que operam em escala. A prática de revisar planos de execução com ferramentas como `EXPLAIN ANALYZE` deve ser rotina em qualquer ciclo de desenvolvimento.