Versionen des Spanner-Abfrageoptimierungstools

Auf dieser Seite werden die verschiedenen Versionen des Spanner-Abfrageoptimierers beschrieben und es wird ein Verlauf der Versionen bereitgestellt. 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 verwendet jede Datenbank spätestens 30 Tage nach Veröffentlichung dieser Version die neueste Version des Optimierungstools.

Sie können die Version des Abfrageoptimierers verwalten, die für Ihre Datenbanken mit GoogleSQL- und PostgreSQL-Dialekt verwendet wird. Bevor Sie sich für die neueste Version entscheiden, können Sie Abfrageleistungsprofile 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 8: 28. Oktober 2024 (Standard und aktuell)

  • WITH-Klauseln werden bei der Auswahl von kostenbasierten Tarifen berücksichtigt.

  • Die Leistung von verteilten Cross-Apply- und indexierten Lookup-Abfragen wurde verbessert.

  • Verbesserte JOIN-Neubestellung

  • 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 wurde hinzugefügt.

  • Unterstützung für die intelligente Auswahl von Seek- und Scan-Plänen basierend auf Statistiken für Abfragen, die keine durchsuchbaren Prädikate für alle wichtigen Teile haben, wurde hinzugefügt.

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

Version 6: 11. September 2023

  • Verbessertes Limit- und Predicate-Pushdown durch Full 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 die Indexauswahl, die Verteilungsverwaltung, die Sortierplatzierung und die GROUP BY-Auswahl.

  • Es wurde Unterstützung für die kostengünstige Auswahl von Join-Algorithmen hinzugefügt, bei der zwischen Hash- und Apply-Join gewählt wird. Für Merge 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 Verwendung sekundärer Indexe bei einem Join zwischen verschränkten Tabellen wurde verbessert.
    • Die Verwendung von abdeckenden sekundären Indexen wurde verbessert.
    • Verbesserte Indexauswahl, wenn die Statistiken des Optimierungstools veraltet sind.
    • Verwenden Sie sekundäre Indexe mit Prädikaten für führende indexierte Spalten, auch wenn die Statistiken des Optimierers nicht verfügbar sind oder die Basistabelle als klein gemeldet wird.

  • 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 Build-Nebeneingabe des Hash-Joins groß ist. Ein Hash-Join in einem Durchgang sollte eine bessere Leistung haben, wenn Sie im Profil der Abfrageausführung Folgendes beobachten:

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

    Wenn die Build-Nebeneingabe des Hash Joins standardmäßig (hash_join_execution=multi_pass) zu groß ist, um in den 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 Build-Seite nicht in den Arbeitsspeicher passt. Die Probe-Seite wird immer nur einmal gescannt.

  • Die Auswahl der Anzahl der für die Suche verwendeten Schlüssel 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 Anweisung:

    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. 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 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