Melhores práticas para criar consultas do Amazon Redshift - AWS Orientação prescritiva

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á.

Melhores práticas para criar consultas do Amazon Redshift

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

Evite usar a instrução SELECT * FROM

Recomendamos que você evite usar a SELECT * FROM declaração. 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 melhores práticas

select sales_date, sales_amt from sales;

Identifique problemas de consulta

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

Obtenha 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. Você pode usar essas informações para otimizar suas consultas.

Evite junções cruzadas

Recomendamos que você evite usar junções cruzadas, a menos que seja absolutamente necessário. Sem uma condição de junção, as junções cruzadas resultam no produto cartesiano de duas tabelas. As junções cruzadas geralmente são executadas como junções de loop aninhado (o mais lento dos tipos de junção possíveis).

Exemplo do que evitar

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

Exemplo de melhores práticas

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

Evite funções em predicados de consulta

Recomendamos que você evite usar funções em predicados de consulta. O uso de funções em predicados de consulta pode afetar negativamente o desempenho, 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 melhores práticas

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

Evite conversões de elenco desnecessárias

Recomendamos que você evite usar a conversão de conversão desnecessária nas consultas, pois os tipos de dados de conversão consomem tempo e recursos e retardam 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 melhores práticas

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

Use expressões CASE para agregações complexas

Recomendamos que você use uma expressão CASE para realizar agregações complexas em vez de selecionar na mesma tabela várias vezes.

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 melhores práticas

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;

Use subconsultas

Recomendamos que você use subconsultas nos casos em que uma tabela na consulta é usada somente para condições de predicado e a subconsulta retorna um pequeno número de linhas (menos de cerca de 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 melhores práticas

Se uma subconsulta retornar maior ou igual a 200 linhas:

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';

Use predicados

Recomendamos que você use 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 especificar quais linhas devem ser incluídas nos resultados da consulta com base nas condições especificadas. Isso permite que você recupere somente os dados nos quais 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.

Adicione predicados para filtrar tabelas com junções

Recomendamos que você adicione predicados às tabelas de filtro que participam das uniões, mesmo que os predicados apliquem os mesmos filtros. O uso de predicados para filtrar tabelas com junções no SQL pode melhorar o desempenho da consulta, reduzindo a quantidade de dados que devem ser processados e reduzindo o tamanho do conjunto intermediário de resultados. Ao especificar as condições para a operação de junção na WHERE cláusula, 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 melhores práticas

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';

Use os operadores mais baratos para predicados

No predicado, use os operadores mais baratos que você puder. Operadores de condição de comparação são preferíveis aos operadores LIKE. LIKEoperadores ainda são preferíveis aos operadores SIMILAR TO ou POSIX.

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

Use chaves de classificação na GROUP BY cláusula 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 GROUP BY lista contém somente colunas de chave de classificação, uma das quais também é a chave de distribuição. As colunas da chave de classificação na GROUP BY lista devem incluir a primeira chave de classificação, seguida por outras chaves de classificação que você deseja usar na ordem da chave de classificação.

Aproveite as visualizações materializadas

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

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

Se você usar ambas as ORDER BY cláusulas GROUP BY e, certifique-se de colocar as colunas na mesma ordem em ambas as GROUP BY ORDER BY cláusulas. GROUP BYexige implicitamente que os dados sejam classificados. Se sua ORDER BY cláusula 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 melhores práticas

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