Laravel é lento? Entenda o que é SARGABLE e por que suas queries não escalam

Muita gente culpa o Laravel pela lentidão da aplicação.
Mas a verdade é que na maioria das vezes o problema não está no framework — está na query.

Antes de entrar nessa discussão, deixa eu te fazer uma pergunta simples:

👉 Você entende a diferença entre essas duas queries?

SELECT * FROM orders WHERE DATE(created_at) = '2025-10-24';

SELECT * FROM orders WHERE created_at BETWEEN '2025-10-24' AND '2025-10-24 23:59:59.999999';

O resultado é o mesmo. Mas o impacto no desempenho é gigantesco.

🚀 O que é SARGABLE (Search ARGument ABLE)

Uma query sargable é aquela que permite o uso de índices na busca.
Em outras palavras, é uma consulta que o otimizador do banco consegue acelerar usando a estrutura de indexação existente.

Quando você faz algo como:

WHERE DATE(created_at) = '2025-10-24'

Você está envolvendo uma coluna indexada em uma função, e isso quebra o uso do índice.
O MySQL (ou qualquer outro SGBD) precisa varrer toda a tabela para calcular o valor da função linha por linha — o famoso full table scan.

Já a segunda query:

WHERE created_at BETWEEN '2025-10-24' AND '2025-10-24 23:59:59.999999'

é sargable — ela permite que o banco use o índice em created_at, reduzindo drasticamente o tempo de busca.

🧠 Testando na prática com o MySQLSLAP

Para comprovar isso, foi usado o utilitário mysqlslap, uma ferramenta nativa do MySQL que simula carga de concorrência.

mysqlslap --concurrency=1,10,40,100 --iterations=3 --query="SELECT ..." --create-schema=meubanco

O teste mostrou que:

• Com 1 usuário, ambas as queries performam bem (diferença imperceptível).
• Com 40 usuários, a query não sargable demorou 4 segundos, enquanto a otimizada levou 800ms.
• Com 100 usuários, a diferença ficou ainda mais brutal: 9 segundos vs 2 segundos.

💡 Ou seja: em ambiente real e com concorrência, o impacto é exponencial.

🧩 Aplicando isso no Eloquent

Esse tipo de erro é muito comum no Laravel.
 Veja o exemplo a seguir:

// ❌ Errado — quebra o índice
Order::whereDate('created_at', $date)->paginate(50);

// ✅ Certo — aproveita o índice
Order::whereBetween('created_at', [
    Carbon::parse($date)->startOfDay(),
    Carbon::parse($date)->endOfDay()
])->paginate(50);

No primeiro caso, o whereDate aplica uma função sobre a coluna e perde a indexação.
No segundo, a busca é direta e totalmente sargable.

Essa diferença pode parecer pequena, mas em produção e sob carga, é o que separa uma aplicação que escala de uma que trava.

🔥 Testando com o Laravel Octane

Para o teste dentro do Laravel, o ambiente foi configurado com Octane (para simular concorrência real).
Utilizando o Pest PHP com testes de estresse, a diferença foi absurda:

QueryRequisições respondidasTempo médioSargable (whereBetween) | 1.732 | 256ms
Não Sargable (whereDate) | 80 | 9s

Essa diferença é o reflexo direto da otimização — o mesmo código, a mesma rota, mas uma abordagem correta.

💬 Conclusão

Antes de dizer que o Laravel é lento, pergunte-se:

• Minhas queries são sargables?
• Estou aproveitando os índices corretamente?
• Meus filtros e funções não estão destruindo a performance?

O problema raramente é o framework — é a forma como você o usa.

Se você quiser ver tudo isso rodando ao vivo, com explicações visuais e testes reais, assista o vídeo completo no canal Beer and Code:

E se quiser aprender a fundo como escrever queries performáticas no Eloquent, sem cair nesses erros bobos, conheça o Clã Beer and Code —
onde nossos alunos aprendem a escrever código que escala de verdade.