Versionen der Spanner-Abfrageoptimierung

Auf dieser Seite wird ein Verlauf der verschiedenen Versionen der Spanner-Abfrageoptimierung beschrieben und bereitgestellt. Die aktuelle Standardversion ist 6. Weitere Informationen 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 ihrer Freigabe die neueste Version der Optimierung.

Wenn Sie eine Datenbank mit GoogleSQL-Dialekt verwenden, können Sie die von Ihren Abfragen verwendete Version der Abfrageoptimierung verwalten. Bevor Sie die neueste Version festlegen, können Sie Abfrageleistungsprofile zwischen älteren Versionen und 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 (aktuelle Version)

• Zusätzliche Unterstützung für die kostenbasierte Auswahl von Index-Union-Plänen.

• 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 Schlüsselteile haben.

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

Version 6: 11. September 2023 (Standardeinstellung)

• Verbessertes Limit-Push und Prädikat-Push durch Full Outer Joins.

• Kardinalitätsschätzung und Kostenmodell wurden verbessert.

• Die kostenbasierte Optimierung für DML-Abfragen wurde aktiviert.

Version 5: 15. Juli 2022

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

• Die Auswahl des Algorithmus für den kostenbasierten Join, bei dem zwischen Hash-Technologie und Join-Anwenden ausgewählt wird, wird jetzt unterstützt. Für das Zusammenführen von Joins ist weiterhin die Verwendung eines Abfragehinweiss erforderlich.

• Die Anfahrt für einen kostenbasierten Join wird jetzt unterstützt.

Version 4: 1. März 2022

• Verbesserungen bei der Auswahl des sekundären Index.

  • Die Verwendung des sekundären Index bei einem Join zwischen verschränkten Tabellen wurde verbessert.
  • Die Abdeckung der sekundären Indexnutzung wurde verbessert.
  • Verbesserte Indexauswahl bei veralteten Optimierungsstatistiken.
  • Sie sollten sekundäre Indexe mit Prädikaten für führende indexierte Spalten bevorzugen, auch wenn die Optimierungsstatistiken nicht verfügbar sind oder die Basistabelle klein ist.

• Stellt den Hash-Join mit einem einzigen Pass 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 Join groß ist. Wenn Sie im Abfrageausführungsprofil Folgendes beobachten, wird von einem Pass-Hash-Join voraussichtlich eine bessere Leistung erzielt:

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

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

• Eine Verbesserung bei der Auswahl, wie viele Schlüssel 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.

  Hinweis zum Kontoauszug:

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

• Der Operator Distributed Merge Union wird eingeführt, der 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 für die Abfrage nicht erforderlich war.

  Betrachten Sie zum Beispiel 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 durch Joins ein Cross Apply-Operator eingeführt wird und die Abfrage sortierte Ergebnisse mit LIMIT anfordert. Nach dieser Änderung wendet das Optimierer die Sortierung mit dem Limit auf der Eingabeseite von "Cross Apply" zuerst 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 durchgeführt werden und es können auch mehr Vorgänge nach unten verschoben werden, die von den übertragenen Berechnungen abhängig sind. Wenn die Abfrage beispielsweise ein Limit hat und die Sortierreihenfolge von diesen Berechnungen abhängt, kann das Limit auch per Join auch ü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

• Weitere Informationen finden Sie unter Informationen zur Abfrageoptimierung.
• Informationen zum Verwalten der Optimierungsversion und des Statistikpakets für Ihr Szenario finden Sie unter Abfrageoptimierung verwalten.