Versionen der Cloud Spanner-Abfrageoptimierung

Auf dieser Seite wird ein Verlauf der verschiedenen Versionen der Cloud Spanner-Abfrageoptimierung beschrieben und bereitgestellt. Die aktuelle Standardversion ist 6. Weitere Informationen zum Abfrageoptimierungstool

Spanner führt Aktualisierungen der Abfrageoptimierung als neue Versionen der Abfrageoptimierung ein. Standardmäßig verwendet jede Datenbank die neueste Version des Optimierungstools frühestens 30 Tage nach ihrer Freigabe.

Wenn Sie eine Datenbank mit GoogleSQL-Dialekt verwenden, können Sie die von Ihren Abfragen verwendete Version des Abfrageoptimierungstools verwalten. Bevor Sie die neueste Version festlegen, können Sie Abfrageleistungsprofile zwischen älteren Versionen und der neuesten Version vergleichen. Weitere Informationen finden Sie unter Abfrageoptimierung verwalten.

Versionsverlauf des Abfrageoptimierungstools

Im Folgenden finden Sie eine Zusammenfassung der Aktualisierungen, die in den einzelnen Versionen am Abfrageoptimierungstool vorgenommen wurden.

Version 6: 11. September 2023 (neueste und Standard)

  • Limit-Pushing und Prädikats-Push über vollständige äußere Joins wurden verbessert.

  • Kardinalitätsschätzung und Kostenmodell wurden verbessert.

  • Die kostenbasierte Optimierung für DML-Abfragen wurde aktiviert.

Version 5: 15. Juli 2022

  • Verbessertes Kostenmodell für Indexauswahl, Verteilungsverwaltung, Sortierplatzierung und GROUP BY-Auswahl.

  • Unterstützung für die Auswahl des kostenbasierten Join-Algorithmus, bei dem zwischen Hash-Technologie und Anwenden von Joins ausgewählt wird. Für Merge Joins ist weiterhin die Verwendung eines Abfragehinweises erforderlich.

  • Unterstützung für kostenbasierte JOIN-Kommutativität hinzugefügt.

Version 4: 1. März 2022

  • Verbesserungen bei der Auswahl des sekundären Index.

    • Verbesserte Verwendung des sekundären Index bei einem Join zwischen verschränkten Tabellen.
    • Die Abdeckung der sekundären Indexnutzung wurde verbessert.
    • Verbesserte Indexauswahl bei veralteten Optimierungsstatistiken.
    • Bevorzugen Sie sekundäre Indexe mit Prädikaten für führende indexierte Spalten, auch wenn die Optimierungsstatistiken nicht verfügbar sind oder wenn die Basistabelle klein ist.

  • Führt einen Hash Join für einzelne Durchgänge ein, aktiviert durch den neuen Hinweis hash_join_execution.

    Teilnahme-Tipp:

    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 */ (...)

    Der neue Modus ist von Vorteil, wenn die Build-Nebeneingabe des Hash Join groß ist. Eine Durchlauf-Hash Join-Operation sollte eine bessere Leistung haben, wenn Sie im Abfrageausführungsprofil Folgendes beobachten:

    • Die Anzahl der Ausführungen im rechten untergeordneten Element des Hash Join ist größer als die Anzahl der Ausführungen im Operator „Hash Join“.
    • Die Latenz im rechten untergeordneten Element des Operators „Hash Join“ ist ebenfalls hoch.

    Wenn die Build-Nebeneingabe des Hash Join zu groß ist, um in den Speicher zu passen, wird die Build-Seite standardmäßig (hash_join_execution=multi_pass) in mehrere Batches aufgeteilt und die Prüfungsseite kann mehrmals gescannt werden. Im neuen Modus (hash_join_execution=one_pass) wird ein Hash Join an das Laufwerk übergeben, wenn seine Build-Nebeneingabe nicht in den Speicher passt. Die Probeseite wird immer nur einmal gescannt.

  • Eine Verbesserung bei der Auswahl, wie viele Schlüssel für die Suche verwendet werden.

Version 3: 1. August 2021

  • Fügt einen neuen Join-Algorithmus hinzu, einen Merge-Join, der mit einem neuen Abfragehinweiswert der JOIN-Methode aktiviert wird.

    Hinweis zur Anweisung:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

    /*@ join_method=merge_join */
SELECT ...

    Join-Tipp:

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=merge_join} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=merge_join */ (...)

  • Fügt einen neuen Join-Algorithmus hinzu, den Hash-Join Push-Broadcast, der mit einem neuen Abfragehinweiswert der JOIN Methode aktiviert ist.

    Join-Tipp:

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=push_broadcast_hash_join} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=push_broadcast_hash_join} */ (...)

  • Einführung des Operators Distributed Merge Union, der gegebenenfalls standardmäßig aktiviert ist. Dieser Vorgang verbessert die Leistung von Abfragen.

  • Eine kleine Verbesserung der Leistung eines Scans unter einem GROUP BY, wenn keine MAX- oder MIN-Aggregate (oder HAVING MAX/MAX) in der SELECT-Liste vorhanden sind. Vor dieser Änderung hat Spanner die zusätzliche nicht gruppierte Spalte geladen, auch wenn sie für die Abfrage nicht benötigt wurde.

    Betrachten Sie zum Beispiel die folgende Tabelle:

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

    Vor dieser Änderung hätte die folgende Abfrage die Spalte c geladen, obwohl sie für die Abfrage nicht erforderlich gewesen wäre.

    SELECT a, b
FROM myTable
GROUP BY a, b

  • Verbessert die Leistung einiger Abfragen mit LIMIT, wenn ein Cross Apply-Operator durch Joins eingeführt wird und die Abfrage nach sortierten Ergebnissen mit LIMIT anfordert. Nach dieser Änderung wendet die Optimierung zuerst die Sortierung mit dem Limit auf der Input-Seite von Cross Apply an.

    Beispiel:

    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;

  • Verbessert die Abfrageleistung, da mehr Berechnungen durch JOIN übertragen werden.

    Überträgt mehr Berechnungen, die eine Unterabfrage oder die Erstellung von Structs über Joins umfassen können. Dadurch wird die Abfrageleistung in mehrfacher Hinsicht verbessert. Beispielsweise können mehr Berechnungen verteilt ausgeführt werden und es können auch mehr Vorgänge nach unten verschoben werden, die von den übertragenen Berechnungen abhängig sind. Wenn die Abfrage beispielsweise ein Limit hat und die Sortierreihenfolge von diesen Berechnungen abhängt, kann das Limit auch per Join übertragen werden.

    Beispiel:

    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: 1. März 2020

  • Fügt Optimierungen bei der Indexauswahl hinzu.
  • Verbessert die Leistung der Prädikate REGEXP_CONTAINS und LIKE unter bestimmten Umständen.
  • Verbessert die Leistung eines Scans unter GROUP BY in bestimmten Situationen.

Version 1: 18. Juni 2019

  • Umfasst viele regelbasierte Optimierungen wie Prädikat-Pushdown, Limit-Pushdown, redundante Join-Funktion und Entfernung redundanter Ausdrücke, um nur einige zu nennen.

  • Verwendet Statistiken zu Nutzerdaten, um auszuwählen, welcher Index für den Zugriff auf die einzelnen Tabellen verwendet werden soll.

Nächste Schritte