Versionen des Spanner-Abfrageoptimierungstools

Auf dieser Seite werden die verschiedenen Versionen des Spanner-Abfrageoptimators beschrieben und ein entsprechender Zeitplan bereitgestellt. Die aktuelle Standardversion ist 7. Weitere Informationen zum Abfrageoptimierungstool finden Sie unter Abfrageoptimierungstool.

Spanner führt Aktualisierungen des Abfrageoptimierungstools als neue Versionen des Abfrageoptimierungstools aus. Standardmäßig verwendet jede Datenbank spätestens 30 Tage nach Veröffentlichung dieser Version die neueste Version des Optimierungstools.

Wenn Sie eine Datenbank mit GoogleSQL-Dialekt verwenden, können Sie die Version des Abfrageoptimierungstools verwalten, die für Ihre Abfragen verwendet wird. Bevor Sie sich für die neueste Version entscheiden, können Sie Abfrageleistungsprofile zwischen älteren Versionen und der neuesten Version vergleichen. Weitere Informationen finden Sie unter Abfrageoptimierungstool verwalten.

Versionsverlauf des Abfrageoptimierungstools

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

Version 8: 28. Oktober 2024 (aktuell)

  • WITH-Klauseln werden bei der Auswahl eines kostenbasierten Plans berücksichtigt.

  • Verbesserte Leistung verteilter CrossApply- und Indexsuchabfragen.

  • Verbesserte JOIN-Neuanordnung.

  • Die Leistung von Abfragen mit großen IN (...)-Klauseln wurde verbessert.

  • Verbesserte GROUP BY-Leistung in bestimmten Fällen.

  • Weitere Verbesserungen, darunter eine effizientere Verarbeitung von Abfragen mit LIMIT, Fremdschlüsseln und Indexauswahl.

Version 7: 22. Mai 2024 (Standard)

  • Unterstützung für die kostenbasierte Auswahl von Index-Union-Plänen hinzugefügt.

  • Unterstützung für die intelligente Auswahl von Such- und Scanplänen basierend auf Statistiken für Abfragen hinzugefügt, die keine suchbaren Prädikate für alle wichtigen Teile haben.

  • Unterstützung für die kostenbasierte Auswahl von Hash-Joins hinzugefügt.

Version 6: 11. September 2023

  • Verbesserte Push-Limits und Push-Prädikate durch Full Outer Joins.

  • Verbesserte Kardinalitätsschätzung und Kostenmodell.

  • Kostenbasierte Optimierung für DML-Abfragen aktiviert

Version 5: 15. Juli 2022

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

  • Unterstützung für die kostenbasierte Auswahl des Join-Algorithmus hinzugefügt, bei der zwischen Hash- und Join-Anwendung ausgewählt wird. Für den Zusammenführen-Join ist weiterhin ein Abfragehinweis erforderlich.

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

Version 4: 1. März 2022

  • Verbesserungen bei der Auswahl sekundärer Indexe.

    • Die Nutzung sekundärer Indexe bei einem Join zwischen verschachtelten Tabellen wurde verbessert.
    • Die Nutzung abdeckender sekundärer Indexe wurde verbessert.
    • Verbesserte Indexauswahl, wenn die Statistiken des Optimierers veraltet sind.
    • Verwenden Sie bevorzugt sekundäre Indexe mit Prädikaten auf führenden indexierten Spalten, auch wenn die Statistiken des Optimierers nicht verfügbar sind oder die Basistabelle klein ist.

  • Einführung des Hash-Joins mit einmaliger Durchlauf, der durch den neuen Hinweis hash_join_execution aktiviert wird.

    Hinweis zum Beitritt:

    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-Seiteneingabe des Hash-Joins groß ist. Ein Hash-Join mit nur einer Durchlaufschleife sollte eine bessere Leistung erzielen, wenn Sie im Abfrageausführungsprofil Folgendes beobachten:

    • Die Anzahl der Ausführungen des rechten untergeordneten Elements des Hash-Joins ist größer als die Anzahl der Ausführungen des Hash-Join-Operators.
    • Die Latenz des rechten untergeordneten Elements des Hash-Join-Operators ist ebenfalls hoch.

    Wenn die Eingabe der Build-Seite des Hash-Joins standardmäßig (hash_join_execution=multi_pass) zu groß ist, um im Arbeitsspeicher zu passen, wird die Build-Seite in mehrere Batches aufgeteilt und die Probeseite wird möglicherweise mehrmals gescannt. Im neuen Modus (hash_join_execution=one_pass) wird ein Hash-Join auf die Festplatte ausgelagert, wenn die Eingabe auf der Build-Seite nicht in den Arbeitsspeicher passt. Die Probeseite wird immer nur einmal gescannt.

  • Die Auswahl der Anzahl der Tasten, die für die Suche verwendet werden, wurde verbessert.

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 Erklärung:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Join-Hinweis:

    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-Hinweis:

    GoogleSQL 

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

    PostgreSQL 

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

  • Führt den Operator Distributed Merge-Union ein, der standardmäßig aktiviert ist. Dadurch wird die Leistung von Abfragen verbessert.

  • 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 von der Abfrage nicht benötigt wurde.

    Betrachten Sie beispielsweise 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 durch Joins eingeführter CrossApply-Operator eingeführt wird und die Abfrage nach sortierten Ergebnissen mit LIMIT fragt. Nach dieser Änderung wendet das Optimierungstool zuerst die Sortierung mit dem Limit auf der Eingabeseite von CrossApply 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 auf verschiedene Weise verbessert. Beispielsweise können mehr Berechnungen verteilt ausgeführt werden. Außerdem können mehr Vorgänge, die von den übertragenen Berechnungen abhängen, bereitgestellt werden. Wenn die Abfrage beispielsweise ein Limit hat und die Sortierreihenfolge von diesen Berechnungen abhängt, kann das Limit auch durch einen 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