Ajuste de desempenho de junções entre várias tabelas
Leia planos de junção, force uma ordem de junção com dicas e reduza a quantidade de linhas intermediárias para manter rápidas as consultas entre várias tabelas.
Ajuste de desempenho de junções entre várias tabelas é uma aula grátis de SQL Academy no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de SQL Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de SQL Academy inclui 4 aulas no total.
JOINs multiplicam as contagens de linhas
Se A tiver 10k linhas correspondentes ao filtro e B tiver 5 correspondências por linha de A, A JOIN B produzirá 50k. Adicione C com 5 correspondências por linha → 250k. As contagens intermediárias de linhas determinam o custo.
Filtre cedo, faça JOIN depois
Aplique os predicados seletivos o mais cedo possível:
-- Slow — filters AFTER joining:
SELECT u.email FROM users u JOIN orders o ON o.user_id = u.id
WHERE u.country = 'US' AND o.total > 1000;
-- Same query, planner usually pushes filters down automatically.
-- For complex queries, force it with a CTE/subquery filter.Crie índices em todas as colunas de JOIN
Cada lado do JOIN deve ter um índice na coluna de JOIN (PK é indexada automaticamente; a FK da tabela filha precisa de um índice explícito):
CREATE INDEX orders_user_id_idx ON orders(user_id);Reduza as colunas para reduzir a memória
Faça SELECT somente das colunas necessárias. Linhas intermediárias largas aumentam excessivamente os buffers de hash e de ordenação:
-- Wide:
SELECT * FROM users u JOIN orders o ON ...
-- Narrow:
SELECT u.id, u.email, o.id, o.total FROM users u JOIN orders o ON ...JOINs em estrela vs floco de neve
Fazer JOIN de uma tabela de fatos com várias tabelas pequenas de dimensões é comum em análises. Certifique-se de que cada dimensão tenha um índice na sua chave.
A ordem dos JOINs importa (às vezes)
O planejador escolhe a ordem dos JOINs, mas, com muitas tabelas (≥ 12), pode desistir de explorar todas as possibilidades. Ajuste join_collapse_limit ou reescreva usando CTEs.
CTEs como barreiras de otimização
No PG ≥ 12, os CTEs são incorporados por padrão. Para forçar a materialização (uma barreira para o planejador), use WITH ... AS MATERIALIZED. Isso é útil quando você quer calcular uma pequena estrutura intermediária uma única vez.
Hash Join vs Merge Join vs Nested Loop
O planejador escolhe com base nas estimativas de linhas. Execute EXPLAIN ANALYZE para ver o que foi escolhido e se as estimativas foram precisas.
EXPLAIN (ANALYZE, BUFFERS)
SELECT ... FROM big_a JOIN big_b ON ...;Estimativas ruins levam a planos ruins
Se rows em EXPLAIN ANALYZE diferir muito de actual rows, as estatísticas estão desatualizadas. Execute ANALYZE; para correlações entre várias colunas, use estatísticas estendidas.
ANALYZE orders;
CREATE STATISTICS orders_country_status (dependencies)
ON country, status FROM orders;Evite funções em colunas indexadas
Funções aplicadas às chaves de JOIN indexadas desativam o uso do índice. Adicione um índice de expressão ou reescreva a consulta:
-- Bad (LOWER on indexed email kills the index):
ON LOWER(u.email) = LOWER(c.email)
-- Better — add a functional index:
CREATE INDEX users_email_lower ON users(LOWER(email));Visões materializadas para JOINs pesados
Se um JOIN de cinco tabelas alimentar um painel, materialize o resultado e atualize-o todas as noites. Troque atualidade por velocidade.
Analise consultas reais
Use pg_stat_statements para encontrar suas consultas mais lentas com vários JOINs. Otimize as que realmente causam impacto.
Recapitulação
JOINs entre várias tabelas dependem de:
- Índices em todas as colunas de JOIN
- Predicados seletivos aplicados antecipadamente
- Estatísticas precisas (ANALYZE)
- Projeções estreitas
- Materialização quando a reutilização compensar a atualidade
Verificação rápida
Você vê que EXPLAIN ANALYZE mostra rows=1 na estimativa, mas actual rows=500000. Qual é a correção mais provável?
Aprenda SQL com um tutor de IA — grátis
Escreva e execute código real no seu navegador, obtenha ajuda instantânea de um tutor de IA 24/7 e continue de onde parou na web ou no app.
- Cursos
- 46
- Aulas
- 183
Perguntas Frequentes
A aula “Ajuste de desempenho de junções entre várias tabelas” é grátis?
Sim — o texto completo de “Ajuste de desempenho de junções entre várias tabelas” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de SQL Academy, atualize para CoddyKit PRO. O curso de SQL Academy inclui 4 aulas no total.
O que vou aprender em “Ajuste de desempenho de junções entre várias tabelas”?
Leia planos de junção, force uma ordem de junção com dicas e reduza a quantidade de linhas intermediárias para manter rápidas as consultas entre várias tabelas. Você pratica SQL Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar SQL Academy?
Nenhuma experiência prévia é necessária. SQL Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Ajuste de desempenho de junções entre várias tabelas”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de SQL Academy?
Sim. Cada aula de SQL Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Junções cruzadas e produtos cartesianos
- Junções laterais (LATERAL JOIN)
- Antijunções e semijunções (NOT EXISTS)
- Ajuste de desempenho de junções entre várias tabelas