Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Bonnes pratiques pour la conception de requêtes Amazon Redshift
<a name="best-practices-designing-queries"></a>

Cette section fournit une vue d'ensemble des meilleures pratiques en matière de conception de requêtes. Nous vous recommandons de suivre les meilleures pratiques décrites dans cette section pour optimiser les performances et l'efficacité des requêtes.

## Évitez d'utiliser l'instruction SELECT \* FROM
<a name="select-from-statement"></a>

Nous vous recommandons d'éviter d'utiliser `SELECT * FROM` cette déclaration. Au lieu de cela, listez toujours les colonnes à analyser. Cela réduit le temps d'exécution des requêtes et analyse les coûts des requêtes Amazon Redshift Spectrum.

**Exemple de ce qu'il faut éviter**

```
select * 
from sales;
```

**Exemple de bonne pratique**

```
select sales_date, sales_amt
from sales;
```

## Identifier les problèmes liés aux requêtes
<a name="query-issues"></a>

Nous vous recommandons de consulter la vue [STL\_ALERT\_EVENT\_LOG pour identifier et corriger les éventuels problèmes](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_ALERT_EVENT_LOG.html) liés à votre requête.

## Obtenez des informations récapitulatives sur votre requête
<a name="summary-info"></a>

Nous vous recommandons d'utiliser les vues SVL\_QUERY\_SUMMARY et [SVL\_QUERY\_REPORT pour obtenir des informations récapitulatives](https://docs.aws.amazon.com/redshift/latest/dg/r_SVL_QUERY_SUMMARY.html) [sur vos requêtes](https://docs.aws.amazon.com/redshift/latest/dg/r_SVL_QUERY_REPORT.html). Vous pouvez utiliser ces informations pour optimiser vos requêtes.

## Évitez les jonctions croisées
<a name="cross-joins"></a>

Nous vous recommandons d'éviter d'utiliser des jonctions croisées, sauf en cas de nécessité absolue. Sans condition de jointure, les jointures croisées produisent le produit cartésien de deux tables. Les jointures croisées sont généralement exécutées sous forme de boucles imbriquées (le type de jointure le plus lent possible).

**Exemple de ce qu'il faut éviter**

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

**Exemple de bonne pratique**

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

## Évitez les fonctions dans les prédicats de requête
<a name="functions-query-predicates"></a>

Nous vous recommandons d'éviter d'utiliser des fonctions dans les prédicats de requête. L'utilisation de fonctions dans les prédicats de requête peut avoir un impact négatif sur les performances, car les fonctions ajoutent généralement une charge de traitement supplémentaire à chaque ligne et ralentissent l'exécution globale de la requête.

**Exemple de ce qu'il faut éviter**

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

**Exemple de bonne pratique**

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

## Évitez les conversions de casting inutiles
<a name="cast-conversions"></a>

Nous vous recommandons d'éviter d'utiliser une conversion par diffusion inutile sur les requêtes, car le casting des types de données prend du temps et des ressources et ralentit l'exécution des requêtes.

**Exemple de ce qu'il faut éviter**

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

**Exemple de bonne pratique**

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

## Utiliser des expressions CASE pour des agrégations complexes
<a name="case-expressions"></a>

Nous vous recommandons d'utiliser une [expression CASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CASE_function.html) pour effectuer des agrégations complexes au lieu de sélectionner plusieurs fois dans la même table.

**Exemple de ce qu'il faut éviter**

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

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

**Exemple de bonne pratique**

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

## Utiliser des sous-requêtes
<a name="subqueries"></a>

Nous vous recommandons d'utiliser des sous-requêtes lorsqu'une table de la requête est utilisée uniquement pour les conditions de prédicat et que la sous-requête renvoie un petit nombre de lignes (moins de 200 environ).

**Exemple de ce qu'il faut éviter**

Si une sous-requête renvoie moins de 200 lignes :

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

**Exemple de bonne pratique**

Si une sous-requête renvoie une valeur supérieure ou égale à 200 lignes :

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

## Utiliser des prédicats
<a name="predicates"></a>

Nous vous recommandons d'utiliser des prédicats pour restreindre le jeu de données autant que possible. Les prédicats sont utilisés en SQL pour filtrer et restreindre les données renvoyées dans une requête. En spécifiant des conditions dans un prédicat, vous pouvez spécifier les lignes qui doivent être incluses dans les résultats de la requête en fonction de conditions spécifiées. Cela vous permet de récupérer uniquement les données qui vous intéressent et d'améliorer l'efficacité et la précision de vos requêtes. Pour plus d'informations, consultez la section [Conditions](https://docs.aws.amazon.com/redshift/latest/dg/r_conditions.html) dans la documentation Amazon Redshift.

## Ajouter des prédicats pour filtrer les tables avec des jointures
<a name="filter-tables-joins"></a>

Nous vous recommandons d'ajouter des prédicats pour filtrer les tables qui participent aux jointures, même si les prédicats appliquent les mêmes filtres. L'utilisation de prédicats pour filtrer les tables comportant des jointures dans SQL peut améliorer les performances des requêtes en réduisant la quantité de données à traiter et en réduisant la taille du jeu de résultats intermédiaires. En spécifiant les conditions de l'opération de jointure dans la `WHERE` clause, le moteur d'exécution des requêtes peut éliminer les lignes qui ne répondent pas aux conditions avant leur jointure. Cela se traduit par un ensemble de résultats réduit et une exécution plus rapide des requêtes.

**Exemple de ce qu'il faut éviter**

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

**Exemple de bonne pratique**

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

## Utilisez les opérateurs les moins chers pour les prédicats
<a name="least-expensive-operators"></a>

Dans le prédicat, utilisez les opérateurs les moins chers possibles. Les opérateurs de [conditions de comparaison](https://docs.aws.amazon.com/redshift/latest/dg/r_comparison_condition.html) sont préférables aux opérateurs [LIKE](https://docs.aws.amazon.com/redshift/latest/dg/r_patternmatching_condition_like.html). `LIKE`les opérateurs sont toujours préférables aux opérateurs [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).

## Utiliser des clés de tri dans les clauses GROUP BY
<a name="group-by-clauses"></a>

Utilisez des clés de tri dans la `GROUP BY` clause afin que le planificateur de requêtes puisse utiliser une agrégation plus efficace. Une requête peut être éligible à une agrégation monophasée lorsque sa `GROUP BY` liste ne contient que des colonnes de clé de tri, dont l'une est également la clé de distribution. Les colonnes de clé de tri de la `GROUP BY` liste doivent inclure la première clé de tri, suivie des autres clés de tri que vous souhaitez utiliser dans l'ordre des clés de tri.

## Tirez parti des vues matérialisées
<a name="materialized-views"></a>

Si possible, réécrivez la requête en remplaçant le code complexe par une vue matérialisée, ce qui améliorera considérablement les performances de la requête. Pour plus d'informations, consultez la section [Création de vues matérialisées dans Amazon](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-overview.html) Redshift dans la documentation Amazon Redshift.

## Faites attention aux colonnes des clauses GROUP BY et ORDER BY
<a name="group-by-order-by"></a>

Si vous utilisez les deux `ORDER BY` clauses `GROUP BY` et, assurez-vous de placer les colonnes dans le même ordre dans `GROUP BY` les deux `ORDER BY` clauses. `GROUP BY`exige implicitement que les données soient triées. Si votre `ORDER BY` clause est différente, les données doivent être triées deux fois.

**Exemple de ce qu'il faut éviter**

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

**Exemple de bonne pratique**

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