Capstone: tuning de workload — query de 30s pra 50ms
⏱ 20 min·⭐ 90 XP
Pré-requisitos (0/1)0%
- ⬜🧩 Particionamento e sharding: quando e como(Database Deep — Postgres Internals)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Projeto
Dataset real (100M+ rows), query inicial lenta (30s+). Diagnosticar, tunar, documentar antes/depois.
Workflow de tuning
🗺️ O ciclo, e a regra que evita otimização inútil
1 · Achar a consulta que custa maisnão a mais lenta
Consulta de 50 ms executada um milhão de vezes custa mais que uma de 5 s por hora.
ENTENDER▼
2 · Ler o plano com tempo realnão só a estimativa
Custo é palpite do planejador. Sem o tempo real, você otimiza contra um número imaginado.
MUDAR UMA COISA▼
3 · Uma mudança por vezcom medição
Índice novo e reescrita ao mesmo tempo impedem saber qual ajudou.
MEDIR▼
4 · Medir de novo, e o efeito colateralescrita também
Índice acelera leitura e desacelera escrita. O ganho líquido é o que importa.
REGISTRAR▼
5 · Registrar o que NÃO funcionouno relatório
Metade das tentativas é neutra. Registrá-las evita que o próximo repita.
-- 1. IDENTIFIQUE (pg_stat_statements)
SELECT query, calls, round(total_exec_time::numeric, 2) AS total_ms,
round((total_exec_time / calls)::numeric, 2) AS mean_ms,
rows
FROM pg_stat_statements
WHERE total_exec_time > 10000
ORDER BY total_exec_time DESC LIMIT 20;
-- 2. DIAGNOSTIQUE (EXPLAIN ANALYZE)
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT u.name, COUNT(*) FROM users u
JOIN orders o ON o.user_id = u.id
WHERE u.country = 'BR' AND o.created_at > '2026-01-01'
GROUP BY u.name ORDER BY 2 DESC LIMIT 10;
-- Ler plano: Seq Scan? Rows estimate off 100x? Sort external?
-- 3. HIPÓTESE + AÇÃO
-- Hipótese A: falta índice em (country, created_at)
CREATE INDEX CONCURRENTLY idx_users_country ON users (country);
CREATE INDEX CONCURRENTLY idx_orders_created_user ON orders (created_at, user_id);
-- 4. MEDIR depois
ANALYZE users; ANALYZE orders;
EXPLAIN ANALYZE ...
-- 5. DOCUMENTAR
-- Query: SELECT u.name, COUNT(*) ...
-- Before: 28.5s, Seq Scan users, Nested Loop
-- After: 45ms, Index Scan both sides, Hash Join
-- Change: 2 indexes added, ANALYZE run
-- Impact: 633x speedup in total db time (pg_stat_statements)Quiz rápido
Qual é o primeiro passo ao afinar uma carga real?
Entregáveis
- Relatório MD: cada query com before/after plan (EXPLAIN ANALYZE)
- Mudança schema (ALTER/INDEX) em migration SQL rastreável
- pg_stat_statements antes vs depois — tempo total economizado
- Graphite/Prometheus dashboard (se prod) mostrando latency drop
- Post-mortem escrito: o que aprendeu, padrão pra replicar em outros projetos
✅
Projeto que paga o salário: DB tuning em prod pode economizar milhares em infra/mês. Este capstone te prepara pra conversa real de performance engineering.
Perguntas frequentes
❓ Por onde começar a otimizar uma consulta lenta?
Pelo plano de execução, não pelo código. Ele diz onde o tempo está e se a estimativa bate com a realidade. As três causas mais comuns, nessa ordem: índice ausente ou inadequado, estatística velha e consulta que traz mais dado do que precisa.
❓ Como saber que a otimização não vai quebrar outra coisa?
Medindo o conjunto de consultas do sistema antes e depois, não uma só. Índice novo acelera leitura e desacelera escrita; desnormalizar acelera relatório e cria risco de divergência. Otimização medida numa consulta é a que degrada o resto em silêncio.
❓ De 30 segundos para 50 milissegundos é realista?
É comum quando a causa é estrutural: varredura completa que passa a usar índice adequado, ou consulta que trazia dez vezes o dado necessário. Ganho dessa ordem quase nunca vem de ajuste de parâmetro do banco — vem de mudar o que a consulta pede.
Fixando
Quiz rápido
Por que otimizar uma consulta pode piorar o sistema como um todo?
Quiz rápido
O que o relatório do capstone precisa demonstrar?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…