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
<a name="best-practices-designing-queries"></a>

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
<a name="select-from-statement"></a>

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
<a name="query-issues"></a>

Recomendamos que você verifique a visualização [STL\_ALERT\_EVENT\_LOG](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_ALERT_EVENT_LOG.html) para identificar e corrigir possíveis problemas com sua consulta.

## Obter informações resumidas sobre sua consulta
<a name="summary-info"></a>

Recomendamos que você use as visualizações [SVL\_QUERY\_SUMMARY](https://docs.aws.amazon.com/redshift/latest/dg/r_SVL_QUERY_SUMMARY.html) e [SVL\_QUERY\_REPORT](https://docs.aws.amazon.com/redshift/latest/dg/r_SVL_QUERY_REPORT.html) para obter informações resumidas sobre suas consultas. É possível usar essas informações para otimizar suas consultas.

## Evitar cross-joins
<a name="cross-joins"></a>

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.
<a name="functions-query-predicates"></a>

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
<a name="cast-conversions"></a>

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
<a name="case-expressions"></a>

Recomendamos usar uma [expressão CASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CASE_function.html) 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
<a name="subqueries"></a>

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
<a name="predicates"></a>

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](https://docs.aws.amazon.com/redshift/latest/dg/r_conditions.html) na documentação do Amazon Redshift.

## Adicionar predicados para filtrar tabelas com junções
<a name="filter-tables-joins"></a>

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
<a name="least-expensive-operators"></a>

No predicado, use os operadores mais baratos possíveis. Operadores de [condição de comparação](https://docs.aws.amazon.com/redshift/latest/dg/r_comparison_condition.html) são preferíveis aos operadores [LIKE](https://docs.aws.amazon.com/redshift/latest/dg/r_patternmatching_condition_like.html). Os operadores `LIKE` ainda são preferíveis aos operadores [SIMILAR TO](https://docs.aws.amazon.com/redshift/latest/dg/pattern-matching-conditions-similar-to.html) ou [POSIX](https://docs.aws.amazon.com/redshift/latest/dg/pattern-matching-conditions-posix.html).

## Usar chaves de classificação nas cláusulas GROUP BY
<a name="group-by-clauses"></a>

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
<a name="materialized-views"></a>

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](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-overview.html) na documentação do Amazon Redshift.

## Ter cuidado com as colunas nas cláusulas GROUP BY e ORDER BY
<a name="group-by-order-by"></a>

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
```