Versionen des Spanner-Abfrageoptimierungstools

Auf dieser Seite werden die verschiedenen Versionen des Spanner-Abfrageoptimierungstools beschrieben und ihr Verlauf dokumentiert. Die aktuelle Standardversion ist 8. Weitere Informationen zum Abfrageoptimierungstool finden Sie unter Übersicht über das Abfrageoptimierungstool.

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

Sie können die Version des Abfrageoptimierungstools verwalten, die von Ihren Abfragen für GoogleSQL- und PostgreSQL-Datenbanken verwendet wird. Bevor Sie sich für die neueste Version entscheiden, können Sie die Profile der Abfrageleistung zwischen früheren 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 9: 21. Juli 2026 (neueste Version)

  • Verbessert die Effizienz von verteilten Apply-Joins (DA-Joins), indem nur die erforderlichen Spalten aus der Eingabe an die Map-Seite des Joins gesendet werden.

  • Wählt automatisch die Indizes für berechnete Spalten aus, wenn derselbe berechnete Ausdruck in einer Abfrage als Filter oder Join-Bedingung verwendet wird.

    Beispiel: Ermöglicht die Auswahl des Index für Singers((LOWER(FirstName))), falls für die folgende Abfrage vorhanden:

    GoogleSQL 

    SELECT s.SingerId, s.FirstName, s.LastName
FROM Singers s
WHERE LOWER(s.FirstName) > 'k'
LIMIT 10;

    PostgreSQL 

    SELECT s.singerid, s.firstname, s.lastname
FROM singers s
WHERE LOWER(s.firstname) > 'k'
LIMIT 10;

  • Verbessert die Leistung der verschachtelten Indexsuche durch Batching und Sortieren von Schlüsseln für effiziente sequenzielle Suchvorgänge im Speicher.

  • Geringfügige Verbesserungen bei der Kardinalitätsschätzung.

  • Bevorzugt heuristisch Pläne mit verteilter Anwendung gegenüber Anwendung mit verteilter Vereinigung auf der Map-Seite, wenn über der Anwendung kein LIMIT vorhanden ist.

  • Wählt Index-Union-Pläne aggressiver aus.

  • Verbessert die Leistung von GROUP BY, indem die scanbasierte Aggregation erweitert wird, um Filterprädikate zu unterstützen, bei denen der Aggregationsschlüssel mit Funktionen verglichen wird, die Konstanten und Parameter enthalten.

  • Ermöglicht die kostenbasierte Planoptimierung für Abfragen, die Tabellen mit benannten Schemas enthalten.

Version 8: 28. Oktober 2024 (Standard)

  • WITH-Klauseln werden bei der kostenbasierten Auswahl von Plänen berücksichtigt.

  • Verbesserte Leistung von verteilten Cross-Apply- und indexierten Suchabfragen.

  • Verbesserte JOIN-Neuanordnung.

  • Verbesserte Leistung von Abfragen mit großen IN (...)-Klauseln.

  • 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

  • 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 nicht für alle Schlüsselteile suchbare Prädikate haben.

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

Version 6: 11. September 2023

  • Verbessertes Limit- und Prädikat-Pushdown durch vollständige Outer-Joins.

  • Verbesserte Kardinalitätsschätzung und verbessertes Kostenmodell.

  • Kostenbasierte Optimierung für DML-Abfragen aktiviert.

Version 5: 15. Juli 2022

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

  • Unterstützung für die kostenbasierte Auswahl von Join-Algorithmen hinzugefügt, die zwischen Hash- und Apply-Join wählen. Für Merge-Joins ist weiterhin ein Abfragehinweis erforderlich.

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

Version 4: 1. März 2022

  • Verbesserungen bei der Auswahl sekundärer Indizes.

    • Verbesserte Verwendung sekundärer Indizes bei einem Join zwischen verschachtelten Tabellen.
    • Verbesserte Verwendung von sekundären Covering-Indizes.
    • Verbesserte Indexauswahl, wenn die Statistiken des Optimierungstools veraltet sind.
    • Bevorzugt sekundäre Indizes mit Prädikaten für führende indexierte Spalten, auch wenn die Statistiken des Optimierungstools nicht verfügbar sind oder angeben, dass die Basistabelle klein ist.

  • Führt den Single-Pass-Hash-Join ein, der durch den neuen Hinweis hash_join_execution aktiviert wird.

    Join-Hinweis:

    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 Eingabe der Build-Seite des Hash-Joins groß ist. Es wird erwartet, dass der Single-Pass-Hash-Join eine bessere Leistung bietet, wenn Sie im Profil der Abfrageausführung Folgendes beobachten:

    • Die Anzahl der Ausführungen für das rechte untergeordnete Element des Hash-Joins ist größer als die Anzahl der Ausführungen für den Hash-Join-Operator.
    • Die Latenz für das rechte untergeordnete Element des Hash-Join-Operators ist ebenfalls hoch.

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

  • Verbesserung bei der Auswahl der Anzahl der für die Suche verwendeten Schlüssel.

Version 3: 1. August 2021

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

    Abfragehinweis:

    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 JOIN METHOD Abfragehinweiswert 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 verteilten Merge-Union Operator ein, der standardmäßig aktiviert ist, wenn er anwendbar ist. Diese Operation 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 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 Cross-Apply-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 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 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 von REGEXP_CONTAINS- und LIKE-Prädikaten unter bestimmten Umständen.
  • Verbessert die Leistung eines Scans unter einem 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