Versionen der Spanner-Abfrageoptimierung

Auf dieser Seite werden die verschiedenen Spanner-Abfragen beschrieben und im Verlauf angezeigt. Optimierungstools. Die aktuelle Standardversion ist 6. Weitere Informationen zur Abfrageoptimierung finden Sie unter Informationen zur Abfrageoptimierung.

Spanner führt Aktualisierungen der Abfrageoptimierung als neue Abfrage ein Optimierungstools. Standardmäßig verwendet jede Datenbank die neueste Optimierungstool erst 30 Tage nach der Veröffentlichung der Version.

Wenn Sie eine GoogleSQL-Dialektdatenbank verwenden, können Sie die Version der Abfrageoptimierung verwalten, das in Ihren Abfragen verwendet wird. Bevor Sie sich für die neueste Version entscheiden, können Sie Abfrageleistungsprofile zwischen älteren und aktuellen Versionen ab. Bis 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.

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

  • 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 und Sortierung Placement und GROUP BY-Auswahl.

  • Die Auswahl des kostenbasierten Join-Algorithmus wird jetzt unterstützt, bei der zwischen folgenden Optionen gewählt wird: und Join anwenden. 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.
    • Sekundärindexe mit Prädikaten für führende indexierte Spalten bevorzugen Optimierungsstatistik nicht verfügbar oder Basistabelle wird gemeldet ist klein.

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

    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 nützlich, wenn die Build-Nebeneingabe des Hash Join groß ist. Es wird erwartet, dass ein Hash Join für eine Karte/das Ticket eine bessere Leistung erzielt, wenn Sie Achten Sie im Abfrageausführungsprofil auf Folgendes:

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

    Standardmäßig (hash_join_execution=multi_pass), wenn die Build-Nebeneingabe der Hash Join zu groß ist, um in den Arbeitsspeicher zu passen, ist die Build-Seite in und die Prüfungsseite möglicherweise mehrmals gescannt wird. Mit der Modus (hash_join_execution=one_pass), wird ein Hash-Join an das Laufwerk übergeben, wenn Die Build-Nebeneingabe kann nicht in den Arbeitsspeicher passen und scannt immer die Prüfung Seite 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} */ (...)

  • Einführung in Distributed Merge Union die gegebenenfalls standardmäßig aktiviert ist. Dieser Vorgang verbessert die Abfrageleistung.

  • 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 selbst wenn dies für die Abfrage nicht erforderlich ist.

    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 eine durch Joins eingeführt und die Abfrage angefragt nach sortierten Ergebnisse mit LIMIT. Nach dieser Änderung wendet das Optimierer die Sortierung an Dabei muss zuerst das Limit auf der Eingabeseite von Cross angewendet werden.

    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, wie zum Beispiel: Es können mehr Berechnungen in verteilter Form und mehr Vorgänge durchgeführt werden die von den Push-Berechnungen abhängen, können ebenfalls verschoben werden. Für Beispiel: Die Abfrage hat ein Limit und die Sortierreihenfolge hängt davon ab, kann der Grenzwert auch über 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 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 welche verwendet werden soll .

Nächste Schritte