Versionen der Spanner-Abfrageoptimierung

Auf dieser Seite werden die verschiedenen Versionen der Spanner-Abfrageoptimierung beschrieben und bereitgestellt. Die aktuelle Standardversion ist 6. Weitere Informationen zur Abfrageoptimierung finden Sie unter Informationen zur Abfrageoptimierung.

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

Wenn Sie eine GoogleSQL-Dialekt-Datenbank verwenden, können Sie die Version der Abfrageoptimierung verwalten, die von Ihren Abfragen verwendet wird. Bevor Sie sich für die neueste Version entscheiden, können Sie die Abfrageleistungsprofile älterer Versionen mit 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 7: 22. Mai 2024 (aktuell)

  • Die kostenbasierte Auswahl von Index-Union-Plänen wird jetzt unterstützt.

  • Zusätzliche Unterstützung für die intelligente Auswahl von Such- und Scanplänen auf der Grundlage von Statistiken für Abfragen, die keine suchbaren Prädikate für alle Schlüsselteile haben.

  • Die kostenbasierte Auswahl von Hash-Joins wird jetzt unterstützt.

Version 6: 11. September 2023 (Standard)

  • Verbessertes Limit-Pushen und Prädikats-Pushen durch Full Outer Joins.

  • Kardinalitätsschätzung und Kostenmodell wurden verbessert.

  • Aktivierung der kostenbasierten Optimierung für DML-Abfragen.

Version 5: 15. Juli 2022

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

  • Die Auswahl des kostenbasierten Join-Algorithmus, mit dem zwischen „Hash“ und „Apply Join“ ausgewählt wird, wird jetzt unterstützt. Für Merge Join ist weiterhin die Verwendung eines Abfragehinweises erforderlich.

  • Die nutzungsbasierte Verknüpfung mit Joins wird jetzt unterstützt.

Version 4: 1. März 2022

  • Verbesserungen bei der Auswahl des sekundären Index.

    • Verbesserte Nutzung sekundärer Indexe bei einem Join zwischen verschränkten Tabellen.
    • Verbesserte Abdeckung der Nutzung sekundärer Indexe.
    • Verbesserte Indexauswahl, wenn Optimierungsstatistiken veraltet sind.
    • Bevorzugen Sie sekundäre Indexe mit Prädikaten für führende indexierte Spalten, auch wenn die Optimierungsstatistiken nicht verfügbar sind oder die Basistabelle klein ist.

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

    Hinweis zur Teilnahme:

    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 vorteilhaft, wenn die Build-Nebeneingabe des Hash Join groß ist. Mit One Pass-Hash Join wird voraussichtlich eine bessere Leistung erzielt, wenn Sie Folgendes im Abfrageausführungsprofil beachten:

    • Die Anzahl der Ausführungen auf dem rechten untergeordneten Element des Hash-Join ist größer als die Anzahl der Ausführungen beim Operator „Hash Join“.
    • Auch die Latenz für das rechte untergeordnete Element des Hash-Join-Operators ist hoch.

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

  • Eine verbesserte Auswahl, wie viele Tasten 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.

    Anweisungshinweis:

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

  • Stellt den Operator Distributed Merge Union vor, der gegebenenfalls standardmäßig aktiviert ist. Durch diesen Vorgang 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 für die Abfrage nicht erforderlich war.

    Sehen Sie sich zum Beispiel die folgende Tabelle an:

    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 durch Joins ein Cross-Apply-Operator verwendet wird und die Abfrage mit LIMIT sortierte Ergebnisse anfordert. Nach dieser Änderung wendet das Optimierer 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. Dies verbessert die Abfrageleistung in vielerlei Hinsicht, zum Beispiel: Es können mehr Berechnungen auf verteilte Weise durchgeführt werden und mehr Vorgänge, die von den Push-Berechnungen abhängig sind, können auch nach unten verschoben werden. Wenn die Abfrage beispielsweise ein Limit hat und die Sortierreihenfolge von diesen Berechnungen abhängt, kann das Limit auch über 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 unter bestimmten Umständen die Leistung der Prädikate REGEXP_CONTAINS und LIKE.
  • 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