As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Práticas recomendadas para criar consultas do Amazon Redshift

Esta seção fornece uma visão geral das práticas recomendadas para criar consultas. Recomendamos que você siga as práticas recomendadas desta seção para obter performance e eficiência de consulta ideais.

Evitar usar a instrução SELECT * FROM

Recomendamos que você evite usar a instrução SELECT * FROM. Em vez disso, sempre liste as colunas para análise. Isso reduz o tempo de execução da consulta e verifica os custos das consultas do Amazon Redshift Spectrum.

Exemplo do que evitar

select * 
from sales;

Exemplo de práticas recomendadas

select sales_date, sales_amt
from sales;

Identificar problemas de consultas

Recomendamos que você verifique a visualização STL_ALERT_EVENT_LOG para identificar e corrigir possíveis problemas com sua consulta.

Obter informações resumidas sobre sua consulta

Recomendamos que você use as visualizações SVL_QUERY_SUMMARY e SVL_QUERY_REPORT para obter informações resumidas sobre suas consultas. É possível usar essas informações para otimizar suas consultas.

Evitar cross-joins

Recomendamos evitar usar cross-joins, a menos que isso seja absolutamente necessário. Sem uma condição de junção, os cross-joins resultam no produto cartesiano de duas tabelas. Cross-joins são normalmente executados como junções de loops aninhados (os tipos mais lentos de junções possíveis).

Exemplo do que evitar

select c.c_name, 
          n.n_name 
from tpch.customer c, 
        tpch.nation n;

Exemplo de práticas recomendadas

select c.c_name, 
           n.n_name 
from tpch.customer c, 
join tpch.nation n
  on n.n_nationkey = c.c_nationkey;

Evitar funções em predicados de consultas.

Recomendamos que evite usar funções em predicados de consultas. O uso de funções em predicados de consultas pode afetar negativamente a performance, pois as funções geralmente adicionam sobrecarga de processamento extra a cada linha e retardam a execução geral da consulta.

Exemplo do que evitar

select sum(o_totalprice)
from tpch.orders
where datepart(year, o_orderdate) = 1992;

Exemplo de práticas recomendadas

select sum(o_totalprice)
from tpch.orders
where o_orderdate between '1992-01-01' and '1992-12-31';

Evitar conversões de cast desnecessárias

Recomendamos que você evite usar a conversão de cast desnecessária nas consultas, pois a conversão de tipos de dados consome tempo e recursos e retarda a execução da consulta.

Exemplo do que evitar

select sum(o_totalprice)
from tpch.orders
where o_ordertime::date = '1992-01-01';

Exemplo de práticas recomendadas

select sum(o_totalprice)
from tpch.orders
where o_ordertime between '1992-01-01 00:00:00' and '1992-12-31 23:59:59';

Usar expressões CASE para agregações complexas

Recomendamos usar uma expressão CASE para executar agregações complexas em vez de selecionar várias vezes da mesma tabela.

Exemplo do que evitar

select sum(sales_amt) as us_sales
from sales
where country = 'US';

select sum(sales_amt) as ca_sales
from sales
where country = 'CA';

Exemplo de práticas recomendadas

select sum(case when country = 'US' then sales_amt end) as us_sales,
           sum(case when country = 'CA' then sales_amt end) as ca_sales
from sales;

Usar subconsultas

Recomendamos usar subconsultas em casos em que uma tabela na consulta é usada apenas para condições de predicado e a subconsulta retorna uma pequena quantidade de linhas (menos que aproximadamente 200).

Exemplo do que evitar

Se uma subconsulta retornar menos de 200 linhas:

select sum(order_amt) as total_sales
from sales
where region_key IN
        (select region_key
         from regions
         where state = 'CA');

Exemplo de práticas recomendadas

Se uma subconsulta retornar 200 linhas ou mais:

select sum(o.order_amt) as total_sales
from sales o
join regions r
  on r.region_key = o.region_key
  and r.state = 'CA';

Usar predicados

Recomendamos usar predicados para restringir o conjunto de dados o máximo possível. Os predicados são usados no SQL para filtrar e restringir os dados retornados em uma consulta. Ao especificar condições em um predicado, você pode determinar quais linhas devem ser incluídas nos resultados da consulta com base nas condições especificadas. Isso permite que você recupere somente os dados em que está interessado e melhora a eficiência e a precisão de suas consultas. Para obter mais informações, consulte Condições na documentação do Amazon Redshift.

Adicionar predicados para filtrar tabelas com junções

Recomendamos adicionar predicados para filtrar tabelas que participam em junções, mesmo se os predicados aplicarem os mesmos filtros. O uso de predicados para filtrar tabelas com junções no SQL pode melhorar a performance da consulta, reduzindo a quantidade de dados que devem ser processados e o tamanho do conjunto intermediário de resultados. Ao especificar as condições para a operação de junção na cláusula WHERE, o mecanismo de execução da consulta pode eliminar linhas que não correspondem às condições antes de serem unidas. Isso resulta em um conjunto de resultados menor e na execução mais rápida da consulta.

Exemplo do que evitar

select p.product_name, sum(o.order_amt)
from sales o
join product p
   on r.product_key = o.product_key
where o.order_date > '2022-01-01';

Exemplo de práticas recomendadas

select p.product_name, sum(o.order_amt)
from sales o
join product p
  on p.product_key = o.product_key
  and p.added_date > '2022-01-01'
where o.order_date > '2022-01-01';

Usar os operadores mais baratos para predicados

No predicado, use os operadores mais baratos possíveis. Operadores de condição de comparação são preferíveis aos operadores LIKE. Os operadores LIKE ainda são preferíveis aos operadores SIMILAR TO ou POSIX.

Usar chaves de classificação nas cláusulas GROUP BY

Use chaves de classificação na cláusula GROUP BY para que o planejador de consultas possa usar uma agregação mais eficiente. Uma consulta pode se qualificar para agregação de uma fase quando sua lista de GROUP BY contiver apenas colunas de chave de classificação, em que uma delas também seja a chave de distribuição. As colunas de chave de classificação na lista de GROUP BY devem incluir a primeira chave de classificação, seguida pelas outras chaves de classificação que você deseja usar por ordem de chave de classificação.

Aproveitar as visões materializadas

Se possível, reescreva a consulta substituindo o código complexo por uma visão materializada, o que melhorará significativamente a performance da consulta. Para obter mais informações, consulte Criar visões materializadas no Amazon Redshift na documentação do Amazon Redshift.

Ter cuidado com as colunas nas cláusulas GROUP BY e ORDER BY

Se você usar ambas as cláusulas GROUP BY e ORDER BY, certifique-se de colocar as colunas na mesma ordem nas duas cláusulas GROUP BY e ORDER BY. A claúsula GROUP BY exige implicitamente que os dados sejam classificados. Se sua cláusula ORDER BY for diferente, os dados deverão ser classificados duas vezes.

Exemplo do que evitar

select a, b, c, sum(d)
from a_table
group by b, c, a
order by a, b, c

Exemplo de práticas recomendadas

select a, b, c, sum(d)
from a_table
group by a, b, c
order by a, b, c