CTEs em SQL: Transforme Queries de 45 Segundos em 0.8 Segundos Se você trabalha com dados, já passou por aquela query que demora uma eternidade para executar. Subqueries aninhadas, JOINs em cascata, CASE WHEN nested — tudo conspirando para deixar sua análise mais lenta. A boa notícia? Tem uma solução simples que a maioria não conhece: Common Table Expressions (CTEs). Este artigo te mostra como transformar uma query de 45 segundos em apenas 0.8 segundos. Sem mudar a lógica. Sem adicionar complexidade. Só reordenando como o SQL executa. O Problema: Queries Aninhadas e Subqueries Quando você escreve uma query com subqueries aninhadas, o SQL parser trabalha de baixo para cima: O que acontece aqui? 1. Parser executa a subquery mais interna (filtro de clientes ativos) 2. Executa a subquery do meio (soma por cliente) 3. Executa a subquery mais externa (filtra por total gasto) 4. Executa a subquery correlacionada (conta de pedidos) para cada linha Resultado: o SQL recalcula a mesma coisa várias vezes. A complexidade explode. A Solução: CTEs (WITH Clause) CTEs permitem dividir a query em partes nomeadas, executadas de cima para baixo: Por que isso é mais rápido? 1. CTEs são materializadas: o SQL calcula a CTE uma única vez 2. Evita recalculos: em subqueries correlacionadas, você recalculava para cada linha 3. Parser otimiza melhor: o SQL vê a lógica inteira e consegue otimizar melhor 4. Mais legível: é como pseudocódigo — você lê de cima para baixo Exemplo Real: Redução de 45s para 0.8s Vamos a um caso concreto. Uma empresa analisa vendas de 50 milhões de transações: O problema? A subquery executa 3 vezes para cada cliente (uma no CASE WHEN, uma no WHERE). Aqui está a versão com CTE: Resultado: 45s → 0.8s (55x mais rápido) Por que? A CTE calcula COUNT() e SUM() uma única vez O CASE WHEN referencia (já calculado) em vez de rodar a subquery 3 vezes O JOIN é executado 1 vez, não N vezes Quando Usar CTEs CTEs são ótimas para: ✅ Queries com subqueries correlacionadas — você recalcula dados repetidamente ✅ Múltiplos JOINs complexos — CTEs deixam o código legível ✅ Dados agregados intermediários — cálculos de SUM/COUNT/AVG que você usa várias vezes ✅ Lógica condicional — CASE WHEN que referencia o mesmo cálculo Cuidado com: ⚠️ CTEs muito grandes podem ser materializadas em memória (melhor em DataWarehouse que em MySQL pequeno) ⚠️ Nem todo SQL engine materializa CTEs igualmente (BigQuery vs Snowflake vs PostgreSQL diferem) Dica Bônus: CTEs Recursivas Para casos avançados (gráficos, hierarquias), CTEs recursivas são poderosas: Isso percorre toda a hierarquia de categorias sem subqueries aninhadas. Checklist: Otimizando suas Queries Antes de enviar sua query para produção: [ ] Você tem subqueries correlacionadas (rodando N vezes)? [ ] Você tem múltiplas subqueries calculando a mesma coisa? [ ] A query é tão aninhada que você mesmo está perdido? [ ] Você tem múltiplos JOINs que poderiam ser agrupados em uma CTE intermediária? Se respondeu "sim" a qualquer uma, considere refatorar com CTEs. Conclusão CTEs não são apenas um detalhe de SQL — são uma ferramenta estratégica para performance. Uma mudança simples de sintaxe pode significar a diferença entre uma query que demora 45 segundos e uma que demora menos de 1 segundo. A próxima vez que sua query estiver lenta, antes de reclamar da performance do banco de dados, pergunte-se: "Será que estou deixando o SQL fazer recálculos desnecessários?" Quer aprofundar em SQL otimizado? Conheça o Elite Data Academy — cursos estruturados sobre SQL, Python, BigQuery e análise de dados com foco em performance e boas práticas.