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 zum Abfrageoptimierungstool finden Sie unter Abfrageoptimierungstool.

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 Abfrage von Leistungsprofilen zwischen älteren und aktuellen Versionen. 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.

• Zusätzliche 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

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

Version 6: 11. September 2023 (Standard)

• Verbesserte Push-Limits und Push-Prädikate 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 die Indexauswahl, die Verteilungsverwaltung, die Sortierung und die 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.

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

Version 4: 1. März 2022

• Verbesserungen bei der Auswahl sekundärer Indexe.

  • Verbesserte Nutzung sekundärer Indexe bei einem Join zwischen verschränkten Tabellen.
  • Verbesserte Abdeckung der Nutzung sekundärer Indexe.
  • Verbesserte Indexauswahl, wenn die Statistiken des Abfrageoptimierungstools veraltet sind.
  • Verwenden Sie vorzugsweise 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 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. Die Leistung mit einem Hash Join ist besser, wenn Sie Achten Sie im Abfrageausführungsprofil auf Folgendes:

  • 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.
  • Auch die Latenz für das rechte untergeordnete Element des Hash-Join-Operators ist 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. 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.

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

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

  GoogleSQL

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

  PostgreSQL

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

• Einführung von Distributed Merge Union die gegebenenfalls 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.

  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. Die Abfrage fragt nach sortierten Ergebnisse mit LIMIT. 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. 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. 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 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

• Weitere Informationen zum Abfrageoptimierungstool finden Sie unter Abfrageoptimierungstool.
• Um sowohl die Optimierungsversion als auch das Statistikpaket für Ihr finden Sie unter Abfrageoptimierung verwalten.