Identifier les requêtes qui peuvent bénéficier de l’optimisation de la recherche¶

L’optimisation de la recherche peut améliorer les performances de nombreuses requêtes. Cette rubrique décrit les caractéristiques des types de requêtes pour lesquelles l’optimisation de la recherche est la plus utile et, inversement, les types de requêtes pour lesquelles elle n’est pas utile.

Caractéristiques générales des requêtes¶

L’optimisation de la recherche permet d’améliorer les performances des types de requêtes suivants :

La requête porte sur une ou plusieurs colonnes autres que la clé de cluster principale.
La requête s’exécute généralement pendant quelques secondes ou plus (avant l’application de l’optimisation de la recherche). Dans la plupart des cas, l’optimisation de la recherche n’améliorera pas sensiblement les performances d’une requête dont le temps d’exécution est inférieur à la seconde.
Au moins une des colonnes auxquelles l’opération de filtrage de la requête a permis d’accéder comporte au moins 100 000 valeurs distinctes.

Pour déterminer le nombre de valeurs distinctes, vous pouvez utiliser l’une des méthodes suivantes :
- Utilisez APPROX_COUNT_DISTINCT pour obtenir le nombre approximatif de valeurs distinctes :
  select approx_count_distinct(column1) from table1;
  Copy
- Utilisez COUNT(DISTINCT <nom_colonne>) pour obtenir le nombre réel de valeurs distinctes :
  select count(distinct c1), count (distinct c2) from test_table;
  Copy
Etant donné que vous n’avez besoin que d’une approximation du nombre de valeurs distinctes, pensez à utiliser APPROX_COUNT_DISTINCT, qui est généralement plus rapide et plus économique que COUNT(DISTINCT <nom_colonne>).

Types de données pris en charge¶

Le service d’optimisation de la recherche prend actuellement en charge les types de données suivants :

Nombres à virgule fixe (par exemple INTEGER, NUMERIC).
DATE, TIME et TIMESTAMP.
VARCHAR.
BINARY.
VARIANT, OBJECT et ARRAY.
GEOGRAPHY.

Les requêtes portant sur d’autres types de valeurs (par exemple, FLOAT, GEOMETRY) n’en bénéficient pas.

Types de prédicats pris en charge¶

L’optimisation de la recherche peut améliorer la performance des requêtes utilisant ce type de prédicats :

Autres améliorations potentielles¶

L’optimisation de la recherche peut également améliorer les performances des vues et des requêtes qui utilisent JOIN.

Vues¶

Le service d’optimisation de la recherche peut indirectement améliorer les performances des vues (y compris les vues sécurisées). Si l’optimisation de la recherche est activée dans une table de base pour une vue et si la requête utilise un prédicat sélectif pour cette table, le service d’optimisation de la recherche peut améliorer les performances lors du filtrage des lignes. Voir Types de prédicats pris en charge.

L’optimisation de la recherche n’a pas besoin d’être activée sur toutes les tables de la vue. L’optimisation de la recherche est effectuée sur chaque table indépendamment.

Jointures¶

Le service d’optimisation de la recherche n’améliore pas directement les performances des jointures. Cependant, cela peut améliorer les performances de filtrage des lignes d’une table avant la jointure. Cette amélioration peut se produire lorsque l’optimisation de la recherche est activée dans la table et que le prédicat est sélectif, comme évoqué sous Types de prédicats pris en charge.

L’optimisation de la recherche n’a pas besoin d’être activée dans les deux tables. La décision d’utiliser l’optimisation de la recherche est prise pour chaque table indépendamment.

Requêtes qui ne bénéficient pas d’une optimisation de la recherche¶

Actuellement, le service d’optimisation de la recherche ne prend pas en charge les types de données à virgule flottante, GEOMETRY ou d’autres types de données non répertoriés ci-dessus. Snowflake pourrait prendre en charge d’autres types de données à l’avenir.

En outre, le service d’optimisation de la recherche ne prend pas en charge les éléments suivants :

Tables externes.
Vues matérialisées.
Colonnes définies avec une clause COLLATE.
Concaténation de colonnes.
Expressions analytiques.
Correspond aux colonnes de la table (sauf pour les nombres à virgule fixe convertis en chaînes de caractères).

Bien que l’optimisation de la recherche prenne en charge les prédicats avec des conversions implicites et explicites sur les valeurs constantes, elle ne prend pas en charge les prédicats qui convertissent des valeurs dans la colonne de table réelle (sauf pour les conversions de INTEGER et NUMBER à VARCHAR).

Par exemple, les prédicats suivants sont pris en charge, car ils utilisent des conversions implicites et explicites sur des valeurs constantes (et non des valeurs dans la colonne du tableau) :
```
-- Supported predicate
-- (where the string '2020-01-01' is implicitly cast to a date)
WHERE timestamp1 = '2020-01-01';

-- Supported predicate
-- (where the string '2020-01-01' is explicitly cast to a date)
WHERE timestamp1 = '2020-01-01'::date;
```
Copy
Le prédicat suivant n’est pas pris en charge, car il utilise une conversion sur des valeurs dans la colonne de table :
```
-- Unsupported predicate
-- (where values in a VARCHAR column are cast to DATE)
WHERE to_date(varchar_column) = '2020-01-01';
```
Copy
Le service d’optimisation de la recherche prend en compte les valeurs de colonne d’origine et non les valeurs après la conversion. Par conséquent, le service d’optimisation de la recherche n’est pas utilisé pour les requêtes avec ces prédicats.

Comme nous l’avons mentionné précédemment, l’exception à cette règle est la conversion de valeurs NUMBER ou INTEGER en des valeurs VARCHAR dans la colonne de la table. Le service d’optimisation de la recherche prend en charge ce type de prédicat :

-- Supported predicate
-- (where values in a numeric column are cast to a string)
WHERE cast(numeric_column as varchar) = '2'

Copy

L’optimisation de la recherche n’améliore pas les performances des requêtes qui utilisent Time Travel, car l’optimisation de la recherche ne fonctionne que sur les données actives.