Índice composto é a otimização com melhor custo-benefício do MySQL — e a mais mal entendida. O erro clássico: criar índices separados para cada coluna do WHERE e não entender por que o MySQL continua fazendo varredura completa. A resposta está em uma regra: o prefixo mais à esquerda.
Como um índice composto é armazenado
Um índice de múltiplas colunas é uma lista ordenada pela concatenação das colunas — como uma lista telefônica ordenada por sobrenome, depois nome. O índice:
O EXPLAIN é o raio-X do MySQL: mostra o caminho que o otimizador escolheu para executar a consulta. O problema é que o output assusta — 12 colunas, valores como ref_or_null, Using filesort. Este guia traduz cada coluna no que realmente importa.
O básico em 30 segundos
EXPLAIN
SELECT p.id, c.nome
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
WHERE p.status = 'pago'
AND p.criado_em >= '2026-06-01';
A saída tem uma linha por tabela na consulta. A ordem das linhas é a ordem de leitura — o MySQL processa de cima para baixo, então a primeira linha é a tabela “motora” da junção.
Consultas lentas raramente avisam antes de derrubar a aplicação. Elas se acumulam silenciosamente até que um pico de tráfego transforma um problema latente em incidente. Este artigo documenta o método que usamos em diagnósticos de performance: capturar, medir e priorizar — nessa ordem.
1. Ative o slow query log (corretamente)
O primeiro passo é ter dados. Sem histórico de consultas lentas, qualquer otimização é chute. No MySQL 8, a configuração mínima recomendada: