Versions de l'optimiseur de requêtes Spanner

Cette page décrit et fournit un historique des différentes requêtes Spanner et versions de l'optimiseur. 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 nouvelle requête et versions de l'optimiseur. Par défaut, chaque base de données commence à utiliser la dernière version de l'optimiseur au plus tôt 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ées par vos requêtes. Avant de vous engager dans la dernière version, vous pouvez comparer interroger les profils de performances entre les anciennes versions et la dernière version. À Pour en savoir plus, consultez la page 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 en fonction des statistiques pour les requêtes ne comportant pas de prédicats récupérables pour toutes les parties 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

  • Modèle de coût amélioré pour la sélection d'index, la gestion de la distribution et le tri emplacement et GROUP BY sélection.

  • Ajout de la prise en charge de la sélection de l'algorithme de jointure basée sur les coûts qui choisit entre hacher et appliquer une 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.
    • Privilégier 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 indiquent la table de base est petite.

  • Introduction de la jointure de hachage en une seule passe, 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 volumineux. La jointure de hachage en une passe est censée offrir de meilleures performances Observez ce qui suit dans le profil d'exécution de la requête:

    • Le nombre d'exécutions sur l'enfant droite de la jointure de hachage est plus élevé. que le nombre d'exécutions sur l'opérateur hash join.
    • 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 grande pour tenir en mémoire, le côté build est divisé en plusieurs lots et nous pourrions analyser le côté de la vérification plusieurs fois. Avec l'attribut mode nouveau (hash_join_execution=one_pass), une jointure de hachage sera diffusée sur le disque si son entrée côté build ne peut pas tenir dans la mémoire et analysera toujours la vérification 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} */ (...)

  • Introduction de l'union de fusion distribuée 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 les fichiers 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 en cas de l'opérateur cross apply introduit par les jointures et la requête demande de trier résultats avec LIMIT. Après cette modification, l'optimiseur applique le tri avec la limite du 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: Davantage de calculs peuvent être effectués de manière distribuée et plus d'opérations qui dépendent des calculs envoyés peuvent également être repoussés vers le bas. Pour exemple, la requête a une limite et l'ordre de tri dépend de ces les calculs, la limite peut aussi ê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 et LIKE dans 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 à chacune tableau.

Étape suivante