Cette page décrit et fournit un historique des différentes versions de l'optimiseur de requêtes Spanner. La version par défaut actuelle est 6. Pour en savoir plus sur l'optimiseur de requêtes, consultez la page À propos de l'optimiseur de requêtes.
Spanner déploie les mises à jour de l'optimiseur de requêtes en tant que nouvelles versions de l'optimiseur de requêtes. Par défaut, chaque base de données commence à utiliser la dernière version de l'optimiseur au moins 30 jours après la publication de cette version.
Si vous utilisez une base de données avec dialecte GoogleSQL, vous pouvez gérer la version de l'optimiseur de requête utilisée par vos requêtes. Avant de vous engager dans la dernière version, vous pouvez comparer les profils de performances des requêtes entre les anciennes versions et la dernière version. Pour en savoir plus, consultez la section Gérer l'optimiseur de requêtes.
Historique des versions de l'optimiseur de requête
Vous trouverez ci-dessous un récapitulatif des mises à jour apportées à l'optimiseur de requêtes dans chaque version.
Version 7: 22 mai 2024 (dernière version)
Ajout de la prise en charge de la sélection basée sur les coûts des plans d'union d'index.
Ajout de la prise en charge de la sélection intelligente des plans de recherche par rapport aux plans d'analyse basée sur des statistiques pour les requêtes qui ne comportent pas de prédicats consultables pour tous les éléments clés.
Ajout de la prise en charge de la sélection des jointures de hachage basée sur le coût.
Version 6: 11 septembre 2023 (par défaut)
Amélioration du transfert de limite et du prédicat via des jointures externes complètes.
Amélioration de l'estimation de la cardinalité et du modèle de coût
Activation de l'optimisation basée sur les coûts pour les requêtes LMD.
Version 5: 15 juillet 2022
Amélioration du modèle de coût pour la sélection des index, la gestion de la distribution, le tri des emplacements et la sélection des
GROUP BY
.Ajout de la prise en charge de la sélection de l'algorithme de jointure basée sur les coûts qui choisit entre hachage et application de la jointure. La jointure par fusion nécessite toujours l'utilisation d'un indice de requête.
Ajout de la prise en charge de la commutativité des jointures basée sur les coûts.
Version 4: 1er mars 2022
Améliorations apportées à la sélection des index secondaires.
- Amélioration de l'utilisation des index secondaires dans le cadre d'une jointure entre les tables entrelacées.
- Meilleure couverture de l'utilisation des index secondaires.
- La sélection de l'index a été améliorée lorsque les statistiques de l'optimiseur sont obsolètes.
- Préférez les index secondaires avec des prédicats sur les colonnes indexées principales, même si les statistiques de l'optimiseur ne sont pas disponibles ou si la table de base est petite.
Introduction de la jointure de hachage en un seul passage, activée par le nouvel indice
hash_join_execution
.Conseil pour la jointure:
GoogleSQL
SELECT ... FROM (...) JOIN@{join_method=hash_join, hash_join_execution=one_pass} (...)
PostgreSQL
SELECT ... FROM (...) JOIN/*@ join_method=hash_join, hash_join_execution=one_pass */ (...)
Le nouveau mode est utile lorsque l'entrée secondaire de compilation de la jointure de hachage est volumineuse. La jointure de hachage en une passe devrait offrir de meilleures performances lorsque vous observez les éléments suivants dans le profil d'exécution de la requête:
- Le nombre d'exécutions sur l'enfant droit de la jointure de hachage est supérieur au nombre d'exécutions sur l'opérateur de jointure par hachage.
- La latence sur l'enfant droit de l'opérateur de jointure par hachage est également élevée.
Par défaut (
hash_join_execution=multi_pass
), si l'entrée côté compilation de la jointure de hachage est trop volumineuse pour tenir en mémoire, le côté compilation est divisé en plusieurs lots et nous pouvons analyser le côté vérification plusieurs fois. Avec le nouveau mode (hash_join_execution=one_pass
), une jointure de hachage se déverse sur le disque si son entrée côté compilation ne peut pas tenir en mémoire et n'analyse toujours le côté vérification qu'une seule fois.Amélioration de la sélection du nombre de clés à utiliser pour la recherche.
Version 3: 1er août 2021
Ajoute un nouvel algorithme de jointure (jointure par fusion) activé à l'aide d'une nouvelle valeur d'optimisation de requête JOIN METHOD.
Indice pour la déclaration:
GoogleSQL
@{join_method=merge_join} SELECT ...
PostgreSQL
/*@ join_method=merge_join */ SELECT ...
Indice de jointure:
GoogleSQL
SELECT ... FROM (...) JOIN@{join_method=merge_join} (...)
PostgreSQL
SELECT ... FROM (...) JOIN/*@ join_method=merge_join */ (...)
Ajoute un nouvel algorithme de jointure (jointure de hachage push) activé à l'aide d'une nouvelle valeur d'optimisation de requête JOIN METHOD.
Indice de jointure:
GoogleSQL
SELECT ... FROM (...) JOIN@{join_method=push_broadcast_hash_join} (...)
PostgreSQL
SELECT ... FROM (...) JOIN/*@ join_method=push_broadcast_hash_join} */ (...)
Introduit l'opérateur distributed merge union, qui est activé par défaut le cas échéant. Cette opération améliore les performances des requêtes.
Légère amélioration des performances d'une analyse sous un opérateur
GROUP BY
lorsqu'il n'y a pas d'agrégation MAX ou MIN (ou HAVING MAX/MAX) dans la liste SELECT. Avant cette modification, Spanner chargeait la colonne non groupée supplémentaire, même si elle n'était pas requise par la requête.Prenons l'exemple du tableau suivant:
GoogleSQL
CREATE TABLE myTable( a INT64, b INT64, c INT64, d INT64) PRIMARY KEY (a, b, c);
PostgreSQL
CREATE TABLE myTable( a bigint, b bigint, c bigint, d bigint, PRIMARY KEY(a, b, c) );
Avant cette modification, la requête suivante aurait chargé la colonne
c
, même si elle n'est pas requise par la requête.SELECT a, b FROM myTable GROUP BY a, b
Améliore les performances de certaines requêtes avec
LIMIT
lorsqu'un opérateur cross apply est introduit par les jointures et que la requête demande des résultats triés avec LIMIT. Après cette modification, l'optimiseur applique d'abord le tri avec la limite côté entrée de l'application croisée.Exemple :
GoogleSQL
SELECT a2.* FROM Albums@{FORCE_INDEX=_BASE_TABLE} a1 JOIN Albums@{FORCE_INDEX=_BASE_TABLE} a2 USING(SingerId) ORDER BY a1.AlbumId LIMIT 2;
PostgreSQL
SELECT a2.* FROM albums/*@ force_index=_base_table */ a1 JOIN albums/*@ force_index=_base_table */ a2 USING(singerid) ORDER BY a1.albumid LIMIT 2;
Améliore les performances des requêtes en envoyant davantage de calculs via
JOIN
.Transmet plus de calculs pouvant inclure une sous-requête ou une construction de structure via une jointure. Cela améliore les performances des requêtes de plusieurs manières, par exemple : il est possible d'effectuer davantage de calculs de manière distribuée et d'effectuer davantage d'opérations qui dépendent des calculs envoyés. Par exemple, si la requête a une limite et que l'ordre de tri dépend de ces calculs, la limite peut également être appliquée via une jointure.
Exemple :
SELECT t.ConcertDate, ( SELECT COUNT(*) FROM UNNEST(t.TicketPrices) p WHERE p > 10 ) AS expensive_tickets, u.VenueName FROM Concerts t JOIN Venues u ON t.VenueId = u.VenueId ORDER BY expensive_tickets LIMIT 2;
Version 2: 1er mars 2020
- Ajoute des optimisations dans la sélection d'index.
- Améliore les performances des prédicats
REGEXP_CONTAINS
etLIKE
dans certaines circonstances. - Améliore les performances d'une analyse sous un prédicat
GROUP BY
dans certains cas.
Version 1 : 18 juin 2019
Inclut de nombreuses optimisations basées sur des règles, telles que le pushdown de prédicat, le pushdown de limite, la jointure redondante et la suppression d'expressions redondantes.
Utilise des statistiques sur les données utilisateur afin de sélectionner l'index à utiliser pour accéder à chaque table.
Étapes suivantes
- Pour en savoir plus sur l'optimiseur de requêtes, consultez la page À propos de l'optimiseur de requêtes.
- Pour gérer à la fois la version de l'optimiseur et le package de statistiques pour votre scénario, consultez la section Gérer l'optimiseur de requêtes.