Abfragestatistiken

In diesem Dokument werden die Abfragestatistiken beschrieben, die Spanner als integrierte Tabellen bietet. Sie können Statistiken aus den SPANNER_SYS.QUERY_STATS*-Tabellen mithilfe von SQL-Anweisungen abrufen.

Wann Abfragestatistiken verwendet werden sollten

Abfragestatistiken sind nützlich, wenn Sie Leistungsprobleme untersuchen oder Abfragen in Ihrer Spanner-Datenbank optimieren müssen. Mithilfe von Abfragestatistiken können Sie eine hohe CPU-Auslastung untersuchen, eine erhöhte Abfragelatenz beheben oder die Speichernutzung reduzieren.

Auf Abfragestatistiken zugreifen

Spanner stellt die Abfragestatistiken im Schema SPANNER_SYS bereit. Sie können auf folgende Weise auf SPANNER_SYS-Daten zugreifen:

Die folgenden von Spanner bereitgestellten Methoden für einzelne Lesevorgänge unterstützen SPANNER_SYS nicht:

  • Starken Lesevorgang aus einer einzelnen Zeile oder mehreren Zeilen in einer Tabelle durchführen
  • Lesevorgang veralteter Daten aus einer oder mehreren Zeilen in einer Tabelle ausführen.
  • Aus einer einzelnen Zeile oder mehreren Zeilen in einem sekundären Index lesen

Weitere Informationen finden Sie unter Methoden für einzelne Lesevorgänge.

Nach Abfrage gruppierte CPU-Nutzung

In den folgenden Tabellen werden die Abfragen mit der höchsten CPU-Auslastung während eines bestimmten Zeitraums nachverfolgt:

  • SPANNER_SYS.QUERY_STATS_TOP_MINUTE: Abfragen in Intervallen von 1 Minute
  • SPANNER_SYS.QUERY_STATS_TOP_10MINUTE: Abfragen in 10-Minuten-Intervallen
  • SPANNER_SYS.QUERY_STATS_TOP_HOUR: Abfragen in einstündigen Intervallen

Diese Tabellen haben folgende Attribute:

  • Jede Tabelle enthält Daten für nicht überlappende Zeitintervalle der im Tabellennamen angegebenen Dauer.

  • Intervalle basieren auf der Uhrzeit

    • Intervalle von 1 Minute enden zur vollen Minute.
    • 10-Minuten-Intervalle enden alle 10 Minuten ab der vollen Stunde.
    • 1-Stunden-Intervalle enden zur vollen Stunde.

    Beispielsweise sind die neuesten, für SQL-Abfragen verfügbaren Intervalle um 11:59:30 Uhr:

    • 1 Minute: 11:58:00–11:58:59 Uhr
    • 10 Minuten: 11:40:00–11:49:59 Uhr
    • 1 Stunde: 10:00:00–10:59:59 Uhr

  • Spanner gruppiert die Statistiken nach dem Text der SQL-Abfrage. Wenn eine Abfrage Abfrageparameter verwendet oder wenn Spanner Literalwerte automatisch in Parameter umwandelt, gruppiert Spanner alle Ausführungen dieser Abfrage in einer Zeile. Wenn die Abfrage Stringliterale verwendet, die nicht automatisch in Parameter konvertiert werden können, gruppiert Spanner die Statistiken nur, wenn der vollständige Abfragetext identisch ist. Wenn sich der Text unterscheidet, wird jede Abfrage als separate Zeile angezeigt. Bei Batch-DML normalisiert Spanner den Batch, indem aufeinanderfolgende identische Anweisungen vor dem Generieren des Fingerabdrucks dedupliziert werden.

  • Wenn ein Anfrage-Tag vorhanden ist, ist TEXT_FINGERPRINT der Hash des Anfrage-Tags. Andernfalls ist es der Hash des TEXT-Werts. Bei partitionierten DMLs ist TEXT_FINGERPRINT immer der Hash des Werts TEXT.

  • Jede Zeile enthält Statistiken für alle Ausführungen einer bestimmten SQL-Abfrage, für die Spanner im angegebenen Intervall Statistiken erfasst.

  • Wenn Cloud Spanner nicht alle während des Intervalls ausgeführten Abfragen speichern kann, priorisiert das System Abfragen mit der höchsten CPU-Auslastung im angegebenen Intervall.

  • Zu den erfassten Abfragen gehören solche, die abgeschlossen wurden, fehlgeschlagen sind oder vom Nutzer abgebrochen wurden.

  • Eine Teilmenge der Statistiken bezieht sich auf Abfragen, die ausgeführt, aber nicht abgeschlossen wurden:

    • Ausführungsanzahl und durchschnittliche Latenz in Sekunden für alle Abfragen, die nicht erfolgreich waren.

    • Ausführungsanzahl für Abfragen, die zu einer Zeitüberschreitung geführt haben.

    • Ausführungsanzahl für Abfragen, die vom Nutzer abgebrochen oder aufgrund von Problemen mit der Netzwerkverbindung fehlgeschlagen sind.

  • Alle Spalten in den Tabellen können Nullwerte enthalten.

Abfragestatistiken für zuvor ausgeführte partitionierte DML-Anweisungen haben die folgenden Eigenschaften:

  • Jede erfolgreiche partitionierte DML-Anweisung zählt genau als eine Ausführung. Eine partitionierte DML-Anweisung, die fehlgeschlagen ist, abgebrochen wurde oder ausgeführt wird, hat eine Ausführungsanzahl von null.

  • Die Statistiken ALL_FAILED_EXECUTION_COUNT, ALL_FAILED_AVG_LATENCY_SECONDS, CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT und TIMED_OUT_EXECUTION_COUNT werden für partitionierte DMLs nicht erfasst.

  • Die Statistiken für jede zuvor ausgeführte partitionierte DML-Anweisung können in unterschiedlichen Intervallen angezeigt werden. SPANNER_SYS.QUERY_STATS_TOP_10MINUTE und SPANNER_SYS.QUERY_STATS_TOP_HOUR bieten eine aggregierte Ansicht für partitionierte DML-Anweisungen, die innerhalb von 10 Minuten bzw. 1 Stunde abgeschlossen werden. Informationen zum Aufrufen von Statistiken für Anweisungen, die länger als 1 Stunde dauern, finden Sie im Abfragebeispiel.

Tabellenschema

Spaltenname Typ Beschreibung
INTERVAL_END TIMESTAMP Ende des Zeitintervalls, in dem die eingeschlossene Abfrage ausgeführt wurde
REQUEST_TAG STRING Das optionale Anfrage-Tag für diesen Abfragevorgang. Weitere Informationen zur Verwendung von Tags finden Sie unter Fehlerbehebung bei Anfrage-Tags.
QUERY_TYPE STRING Gibt an, ob eine Abfrage ein PARTITIONED_QUERY oder ein QUERY ist. Eine PARTITIONED_QUERY ist eine Abfrage mit einer partitionToken, die von der PartitionQuery API abgerufen wird, oder eine partitionierte DML-Anweisung. Alle anderen Abfragen und DML-Anweisungen werden mit dem Abfragetyp QUERY gekennzeichnet.
TEXT STRING SQL-Abfragetext, verkürzt auf ca. 64 KB

Statistiken für mehrere Abfragen, die denselben Tag-String haben, werden in einer einzelnen Zeile gruppiert, wobei REQUEST_TAG mit diesem Tag-String übereinstimmt. In diesem Feld wird nur der Text einer dieser Abfragen angezeigt, verkürzt auf ca. 64 KB. Bei Batch-DML wird die Gruppe von SQL-Anweisungen in einer einzelnen Zeile zusammengefasst und durch ein Semikolon getrennt. Aufeinanderfolgende identische SQL-Texte werden vor dem Kürzen dedupliziert.
TEXT_TRUNCATED BOOL Ob der Abfragetext gekürzt wurde oder vollständig ist
TEXT_FINGERPRINT INT64 Der Hash des Werts REQUEST_TAG, falls vorhanden; andernfalls der Hash des Werts TEXT. Entspricht dem Feld query_fingerprint im Audit-Log.
EXECUTION_COUNT INT64 Anzahl der Abfragen, die Spanner im Intervall erkannt hat.
AVG_LATENCY_SECONDS FLOAT64 Durchschnittliche Zeit in Sekunden für jede Abfrageausführung in der Datenbank; dieser Durchschnitt schließt die Codierungs- und Übertragungszeit für die Ergebnismenge sowie den Aufwand aus.
AVG_ROWS FLOAT64 Durchschnittliche Anzahl der Zeilen, die die Abfrage zurückgegeben hat
AVG_BYTES FLOAT64 Die durchschnittliche Anzahl der von der Abfrage zurückgegebenen Datenbyte, ohne den Aufwand der Übertragungskodierung
AVG_ROWS_SCANNED FLOAT64 Durchschnittliche Anzahl der Zeilen, die von der Abfrage gescannt wurden, ausgenommen gelöschte Werte
AVG_CPU_SECONDS FLOAT64 Durchschnittliche Anzahl von Sekunden der CPU-Zeit, die Spanner für alle Vorgänge zur Ausführung der Abfrage aufgewendet hat.
ALL_FAILED_EXECUTION_COUNT INT64 Häufigkeit, mit der die Abfrage während des Intervalls fehlgeschlagen ist.
ALL_FAILED_AVG_LATENCY_SECONDS FLOAT64 Durchschnittliche Zeit in Sekunden für jede Abfrageausführung, die in der Datenbank fehlgeschlagen ist dieser Durchschnitt schließt die Codierungs- und Übertragungszeit für die Ergebnismenge sowie den Aufwand aus.
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT INT64 Häufigkeit, mit der die Abfrage vom Nutzer abgebrochen oder aufgrund einer unterbrochenen Netzwerkverbindung während des Intervalls abgebrochen wurde.
TIMED_OUT_EXECUTION_COUNT INT64 Häufigkeit, mit der die Abfrage während des Intervalls das Zeitlimit überschritten hat.
AVG_BYTES_WRITTEN FLOAT64 Durchschnittliche Anzahl der von der Anweisung geschriebenen Byte.
AVG_ROWS_WRITTEN FLOAT64 Durchschnittliche Anzahl der von der Anweisung geänderten Zeilen.
STATEMENT_COUNT INT64 Die Summe der Anweisungen, die in diesem Eintrag zusammengefasst sind. Bei regulären Abfragen und DML entspricht dies der Anzahl der Ausführungen. Bei Batch-DML erfasst Spanner die Anzahl der Anweisungen im Batch.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Wie oft die Abfrage im Rahmen einer Lese-/Schreibtransaktion ausgeführt wurde. Anhand dieser Spalte können Sie feststellen, ob Sie Sperrkonflikte vermeiden können, indem Sie die Abfrage in eine schreibgeschützte Transaktion verschieben.
LATENCY_DISTRIBUTION ARRAY<STRUCT>

Ein Histogramm der Abfrageausführungszeit. Die Werte werden in Sekunden gemessen.

Das Array enthält ein einzelnes Element und hat den folgenden Typ:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Weitere Informationen zu den Werten finden Sie unter Verteilung und Exponentiell.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um die Perzentillatenz aus der Verteilung zu berechnen. Diese Funktion gibt das geschätzte n-te Perzentil zurück. Ein ähnliches Beispiel finden Sie unter 99. Perzentil der Latenz für Abfragen ermitteln.

Weitere Informationen finden Sie unter Perzentile und Verteilungsmesswerte.

AVG_MEMORY_PEAK_USAGE_BYTES FLOAT64

Die durchschnittliche maximale Speichernutzung (in Byte) während einer verteilten Abfrageausführung.

Anhand dieser Statistik können Sie feststellen, bei welchen Abfragen oder Tabellendatengrößen wahrscheinlich Speicherlimits erreicht werden.
AVG_MEMORY_USAGE_PERCENTAGE FLOAT64

Die durchschnittliche Arbeitsspeichernutzung, die während einer verteilten Abfrageausführung erforderlich ist (als Prozentsatz des für diese Abfrage zulässigen Arbeitsspeicherlimits).

In dieser Statistik wird nur der Arbeitsspeicher erfasst, der für die Ausführung der Abfrage erforderlich ist. Einige Operatoren verwenden zusätzlichen Pufferspeicher, um die Leistung zu verbessern. Der zusätzlich verwendete Pufferspeicher ist im Abfrageplan sichtbar, wird aber nicht zur Berechnung von AVG_MEMORY_USAGE_PERCENTAGE verwendet, da der Pufferspeicher für die Optimierung verwendet wird und nicht erforderlich ist.

Anhand dieser Statistik können Sie Abfragen identifizieren, die sich dem Limit für die Speichernutzung nähern und bei einer Zunahme der Datengröße fehlschlagen könnten. Um das Risiko eines Abfragefehlers zu minimieren, lesen Sie die Best Practices für SQL, um diese Abfragen zu optimieren, oder teilen Sie die Abfrage in Teile auf, die weniger Daten lesen.
AVG_QUERY_PLAN_CREATION_TIME_SECS FLOAT64

Die durchschnittliche CPU-Zeit in Sekunden, die für die Abfragekompilierung aufgewendet wurde, einschließlich der Erstellung der Abfragelaufzeit.

Wenn der Wert dieser Spalte hoch ist, verwenden Sie parametrisierte Abfragen.
AVG_FILESYSTEM_DELAY_SECS FLOAT64

Die durchschnittliche Zeit, die die Abfrage mit dem Lesen aus dem Dateisystem oder mit dem Blockieren von Ein-/Ausgaben (E/A) verbringt.

Verwenden Sie diese Statistik, um potenzielle hohe Latenzen zu identifizieren, die durch Dateisystem-E/A verursacht werden. Fügen Sie zur Behebung des Problems einen Index oder eine STORING- (GoogleSQL) oder INCLUDE-Klausel (PostgreSQL) zu einem vorhandenen Index hinzu.
AVG_REMOTE_SERVER_CALLS FLOAT64

Die durchschnittliche Anzahl der Remote-Serveraufrufe (RPC), die von der Abfrage abgeschlossen wurden.

Anhand dieser Statistik können Sie feststellen, ob verschiedene Abfragen, die dieselbe Anzahl von Zeilen scannen, eine sehr unterschiedliche Anzahl von RPCs haben. Die Abfrage mit einem höheren RPC-Wert kann von einem Index oder einer STORING- (GoogleSQL) oder INCLUDE-Klausel (PostgreSQL) profitieren, die einem vorhandenen Index hinzugefügt wird.
AVG_ROWS_SPOOLED FLOAT64

Die durchschnittliche Anzahl der Zeilen, die von der Abfrageanweisung auf ein temporäres Laufwerk (nicht im Arbeitsspeicher) geschrieben wurden.

Verwenden Sie diese Statistik, um Abfragen mit potenziell hoher Latenz zu identifizieren, die speicherintensiv sind und nicht im Arbeitsspeicher ausgeführt werden können. Ändern Sie zur Behebung die JOIN-Reihenfolge oder fügen Sie einen Index hinzu, der einen erforderlichen SORT bereitstellt.
AVG_DISK_IO_COST FLOAT64

Die durchschnittlichen Kosten dieser Abfrage in Bezug auf die HDD-Laufwerkslast von Spanner.

Verwenden Sie diesen Wert, um relative HDD-E/A-Kostenvergleiche zwischen Lesevorgängen in der Datenbank anzustellen. Für die Abfrage von Daten im HDD-Speicher wird die HDD-Laufwerkskapazität der Instanz in Rechnung gestellt. Ein höherer Wert weist darauf hin, dass Sie mehr HDD-Laufwerkslast verwenden und Ihre Abfrage möglicherweise langsamer ist, als wenn sie auf einer SSD ausgeführt würde. Wenn die Festplattenauslastung außerdem die Kapazität erreicht, kann die Leistung Ihrer Abfragen weiter beeinträchtigt werden. Sie können die gesamte HDD-Laufwerkslastkapazität der Instanz als Prozentsatz überwachen. Wenn Sie die HDD-Laufwerkskapazität erhöhen möchten, können Sie Ihrer Instanz weitere Verarbeitungseinheiten oder Knoten hinzufügen. Weitere Informationen finden Sie unter Rechenkapazität ändern. Wenn Sie die Abfrageleistung verbessern möchten, sollten Sie auch in Betracht ziehen, einige Daten auf SSDs zu verschieben.

Für Arbeitslasten, die viele Laufwerk-E/A-Vorgänge verbrauchen, empfehlen wir, häufig verwendete Daten auf SSD-Speicher zu speichern. Daten, auf die von einer SSD zugegriffen wird, verbrauchen keine HDD-Festplattenkapazität. Sie können ausgewählte Tabellen, Spalten oder sekundäre Indexe nach Bedarf auf SSD-Speicher speichern und Daten, auf die selten zugegriffen wird, auf HDD-Speicher belassen. Weitere Informationen finden Sie unter Übersicht über gestaffelten Speicher.
LATENCY_DISTRIBUTION_JSON_STRING STRING

Ein Histogramm der Abfrageausführungszeit. Die Werte werden in Sekunden gemessen.

Eine JSON-kompatible Stringdarstellung der LATENCY_DISTRIBUTION-Statistik. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT, der in der Spalte LATENCY_DISTRIBUTION definiert ist.

Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Diese Spalte enthält die Verteilung.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um die Perzentillatenz aus der Verteilung zu berechnen. Diese Funktion gibt das geschätzte n-te Perzentil zurück. Ein ähnliches Beispiel finden Sie unter 99. Perzentil der Latenz für Abfragen mit der Spalte LATENCY_DISTRIBUTION_JSON_STRING ermitteln.

Weitere Informationen finden Sie unter Perzentile und Verteilungsmesswerte.

AVG_COLUMNAR_READ_SHARE FLOAT64

Der durchschnittliche Prozentsatz der aus dem spaltenbasierten Speicher gelesenen Byte im Verhältnis zu den insgesamt aus dem zeilen- und spaltenbasierten Speicher gelesenen Byte, ausgedrückt als Bruch zwischen 0 und 1.

Verwenden Sie diese Statistik, um die Nutzung der spaltenorientierten Engine in Abfragen zu überwachen. Weitere Informationen finden Sie unter Leistung der spaltenorientierten Engine überwachen.

QUERY_OPTIMIZER_VERSIONS ARRAY<INT64>

Die Versionen des Abfrageoptimierungstools, die für die Abfragen in diesem Zeitfenster verwendet wurden.
STATISTICS_PACKAGE_NAMES ARRAY<STRING>

Die Namen der Statistikpakete, die für die Abfragen in diesem Zeitfenster verwendet wurden.
CPU_SECONDS_DISTRIBUTION ARRAY<STRUCT>

Ein Histogramm der CPU-Zeit, die Spanner für alle Vorgänge zur Ausführung der Abfrage aufgewendet hat. Die Werte werden in Sekunden gemessen.

Das Array hat die folgende Struktur:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Weitere Informationen zu den Werttypen finden Sie unter Verteilung und Exponentiell.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um CPU-Sekunden-Perzentile aus der Verteilung zu berechnen.

CPU_SECONDS_DISTRIBUTION_JSON_STRING STRING

Eine JSON-kompatible Stringdarstellung der Statistik CPU_SECONDS_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT, der in der Spalte CPU_SECONDS_DISTRIBUTION definiert ist.

Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um CPU-Sekunden-Perzentile aus der Verteilung zu berechnen.

ROW_SCANNED_DISTRIBUTION ARRAY<STRUCT>

Ein Histogramm der Anzahl der von der Abfrage gescannten Zeilen, ausgenommen gelöschte Werte.

Das Array hat die folgende Struktur:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Weitere Informationen zu den Werttypen finden Sie unter Verteilung und Exponentiell.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um Perzentile für Zeilen zu berechnen, die aus der Verteilung gescannt wurden.

ROW_SCANNED_DISTRIBUTION_JSON_STRING STRING

Eine JSON-kompatible Stringdarstellung der Statistik ROW_SCANNED_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT, der in der Spalte ROW_SCANNED_DISTRIBUTION definiert ist.

Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um Perzentile für Zeilen zu berechnen, die aus der Verteilung gescannt wurden.

EXECUTION_COUNT, AVG_LATENCY_SECONDS, LATENCY_DISTRIBUTION und LATENCY_DISTRIBUTION_JSON_STRING für fehlgeschlagene Abfragen umfassen Abfragen, die aufgrund einer falschen Syntax fehlgeschlagen sind oder bei denen ein vorübergehender Fehler aufgetreten ist, die aber bei einem erneuten Versuch erfolgreich waren. In diesen Statistiken werden fehlgeschlagene und abgebrochene partitionierte DML-Anweisungen nicht erfasst.

Zusammengefasste Statistiken

Es gibt auch Tabellen, in denen aggregierte Daten für alle Abfragen erfasst werden, für die Spanner in einem bestimmten Zeitraum Statistiken erfasst hat:

  • SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: Abfragen in Intervallen von 1 Minute
  • SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: Abfragen in Intervallen von 10 Minuten
  • SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: Abfragen in Intervallen von 1 Stunde

Diese Tabellen haben folgende Attribute:

  • Jede Tabelle enthält Daten für nicht überlappende Zeitintervalle der Länge, die im Tabellennamen angegeben ist.

  • Die Intervalle beziehen sich auf die Uhrzeit. 1-Minuten-Intervalle enden nach einer vollen Minute, 10-Minuten-Intervalle enden alle 10 Minuten ab Beginn der vollen Stunde, 1-Stunden-Intervalle enden zu jeder vollen Stunde.

    Beispielsweise sind die neuesten, für SQL-Abfragen verfügbaren Intervalle um 11:59:30 Uhr:

    • 1 Minute: 11:58:00–11:58:59 Uhr
    • 10 Minuten: 11:40:00–11:49:59 Uhr
    • 1 Stunde: 10:00:00–10:59:59 Uhr

  • Jede Zeile enthält zusammengefasste Statistiken für alle Abfragen, die während des angegebenen Intervalls über die Datenbank ausgeführt werden. Es gibt nur eine Zeile pro Zeitintervall und enthält abgeschlossene Abfragen, fehlgeschlagene Abfragen und vom Nutzer abgebrochene Abfragen.

  • Die in den TOTAL-Tabellen erfassten Statistiken können Abfragen enthalten, die von Spanner nicht in den TOP-Tabellen erfasst wurden.

  • Einige Spalten in diesen Tabellen werden in Cloud Monitoring als Messwerte bereitgestellt. Die bereitgestellten Messwerte sind:

    • Anzahl der Abfrageausführungen
    • Abfragefehler
    • Abfragelatenzen
    • Anzahl der zurückgegebenen Zeilen
    • Anzahl der gescannten Zeilen
    • Anzahl der zurückgegebenen Byte
    • CPU-Zeit für Abfrage

    Weitere Informationen finden Sie unter Spanner-Messwerte.

Tabellenschema

Spaltenname Typ Beschreibung
INTERVAL_END TIMESTAMP Ende des Zeitintervalls, in dem die eingeschlossene Abfrage ausgeführt wurde
EXECUTION_COUNT INT64 Wie oft Cloud Spanner die Abfrage im angegebenen Zeitraum gesehen hat.
AVG_LATENCY_SECONDS FLOAT64 Durchschnittliche Zeit in Sekunden für jede Abfrageausführung in der Datenbank; dieser Durchschnitt schließt die Codierungs- und Übertragungszeit für die Ergebnismenge sowie den Aufwand aus.
AVG_ROWS FLOAT64 Durchschnittliche Anzahl der Zeilen, die die Abfrage zurückgegeben hat
AVG_BYTES FLOAT64 Die durchschnittliche Anzahl der von der Abfrage zurückgegebenen Datenbyte, ohne den Aufwand der Übertragungskodierung
AVG_ROWS_SCANNED FLOAT64 Durchschnittliche Anzahl der Zeilen, die von der Abfrage gescannt wurden, ausgenommen gelöschte Werte
AVG_CPU_SECONDS FLOAT64 Durchschnittliche Anzahl von Sekunden der CPU-Zeit, die Spanner für alle Vorgänge zur Ausführung der Abfrage aufgewendet hat.
ALL_FAILED_EXECUTION_COUNT INT64 Häufigkeit, mit der die Abfrage während des Intervalls fehlgeschlagen ist.
ALL_FAILED_AVG_LATENCY_SECONDS FLOAT64 Durchschnittliche Zeit in Sekunden für jede Abfrageausführung, die in der Datenbank fehlgeschlagen ist dieser Durchschnitt schließt die Codierungs- und Übertragungszeit für die Ergebnismenge sowie den Aufwand aus.
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT INT64 Häufigkeit, mit der die Abfrage vom Nutzer abgebrochen oder aufgrund einer unterbrochenen Netzwerkverbindung während des Intervalls abgebrochen wurde.
TIMED_OUT_EXECUTION_COUNT INT64 Häufigkeit, mit der die Abfrage während des Intervalls das Zeitlimit überschritten hat.
AVG_BYTES_WRITTEN FLOAT64 Durchschnittliche Anzahl der von der Anweisung geschriebenen Byte.
AVG_ROWS_WRITTEN FLOAT64 Durchschnittliche Anzahl der von der Anweisung geänderten Zeilen.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Die Anzahl der Abfragen, die im Rahmen von Lese-/Schreibtransaktionen ausgeführt wurden. Anhand dieser Spalte können Sie feststellen, ob Sie Sperrkonflikte vermeiden können, indem Sie einige Abfragen in schreibgeschützte Transaktionen verschieben.
LATENCY_DISTRIBUTION ARRAY<STRUCT>

Ein Histogramm der Ausführungszeit für alle Abfragen. Die Werte werden in Sekunden gemessen.

Geben Sie das Array so an:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Weitere Informationen zu den Werten finden Sie unter Verteilung und Exponentiell.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um die Perzentillatenz aus der Verteilung zu berechnen. Diese Funktion gibt das geschätzte n-te Perzentil zurück. Ein ähnliches Beispiel finden Sie unter 99. Perzentil der Latenz für Abfragen ermitteln.

Weitere Informationen finden Sie unter Perzentile und Verteilungsmesswerte.

LATENCY_DISTRIBUTION_JSON_STRING STRING

Ein Histogramm der Abfrageausführungszeit. Die Werte werden in Sekunden gemessen.

Eine JSON-kompatible Stringdarstellung der LATENCY_DISTRIBUTION-Statistik. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT, der in der Spalte LATENCY_DISTRIBUTION definiert ist.

Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Diese Spalte enthält die Verteilung.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um die Perzentillatenz aus der Verteilung zu berechnen. Diese Funktion gibt das geschätzte n-te Perzentil zurück. Ein ähnliches Beispiel finden Sie unter 99. Perzentil der Latenz für Abfragen mit der Spalte LATENCY_DISTRIBUTION_JSON_STRING ermitteln.

Weitere Informationen finden Sie unter Perzentile und Verteilungsmesswerte.

AVG_COLUMNAR_READ_SHARE FLOAT64

Der durchschnittliche Prozentsatz der aus dem spaltenbasierten Speicher gelesenen Byte im Verhältnis zu den insgesamt aus dem zeilen- und spaltenbasierten Speicher gelesenen Byte, ausgedrückt als Bruch zwischen 0 und 1.

Verwenden Sie diese Statistik, um die Nutzung der spaltenorientierten Engine in Abfragen zu überwachen. Weitere Informationen finden Sie unter Leistung der spaltenorientierten Engine überwachen.

CPU_SECONDS_DISTRIBUTION ARRAY<STRUCT>

Ein Histogramm der CPU-Zeit, die Spanner für alle Vorgänge zur Ausführung der Abfrage aufgewendet hat. Die Werte werden in Sekunden gemessen.

Das Array hat die folgende Struktur:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Weitere Informationen zu den Werttypen finden Sie unter Verteilung und Exponentiell.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um CPU-Sekunden-Perzentile aus der Verteilung zu berechnen.

CPU_SECONDS_DISTRIBUTION_JSON_STRING STRING

Eine JSON-kompatible Stringdarstellung der Statistik CPU_SECONDS_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT, der in der Spalte CPU_SECONDS_DISTRIBUTION definiert ist.

Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um CPU-Sekunden-Perzentile aus der Verteilung zu berechnen.

ROW_SCANNED_DISTRIBUTION ARRAY<STRUCT>

Ein Histogramm der Anzahl der von der Abfrage gescannten Zeilen, ausgenommen gelöschte Werte.

Das Array hat die folgende Struktur:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Weitere Informationen zu den Werttypen finden Sie unter Verteilung und Exponentiell.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um Perzentile für Zeilen zu berechnen, die aus der Verteilung gescannt wurden.

ROW_SCANNED_DISTRIBUTION_JSON_STRING STRING

Eine JSON-kompatible Stringdarstellung der Statistik ROW_SCANNED_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT, der in der Spalte ROW_SCANNED_DISTRIBUTION definiert ist.

Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt.

Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um Perzentile für Zeilen zu berechnen, die aus der Verteilung gescannt wurden.

Datenaufbewahrung

Spanner bewahrt Daten für jede Tabelle mindestens für die folgenden Zeiträume auf:

  • SPANNER_SYS.QUERY_STATS_TOP_MINUTE und SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: Intervalle der letzten 6 Stunden.

  • SPANNER_SYS.QUERY_STATS_TOP_10MINUTE und SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: Intervalle der letzten 4 Tage.

  • SPANNER_SYS.QUERY_STATS_TOP_HOUR und SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: Intervalle, die die letzten 30 Tage abdecken.

Beispielabfragen

Dieser Abschnitt enthält mehrere Beispiel-SQL-Anweisungen, die Abfragestatistiken abrufen. Sie können diese SQL-Anweisungen mit den Clientbibliotheken, der Google Cloud CLI oder der Google Cloud Console ausführen.

Grundlegende Statistiken für jede Abfrage in einem bestimmten Zeitraum auflisten

Die folgende Abfrage gibt die Rohdaten für die Top-Abfragen der vorherigen Minute zurück:

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
ORDER BY interval_end DESC;

Statistiken für partitionierte DML-Anweisungen auflisten, die länger als eine Stunde ausgeführt werden

Die folgende Abfrage gibt die Anzahl der Ausführungen und die durchschnittliche Anzahl der Zeilen zurück, die von den wichtigsten partitionierten DML-Abfragen in den letzten Stunden geschrieben wurden:

SELECT text,
       request_tag,
       interval_end,
       sum(execution_count) as execution_count,
       sum(avg_rows_written*execution_count)/sum(execution_count) as avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE starts_with(text, "UPDATE") AND query_type = "PARTITIONED_QUERY"
group by text, request_tag, interval_end
ORDER BY interval_end DESC;

Abfragen mit der höchsten CPU-Auslastung auflisten

Die folgende Abfrage gibt die Abfragen mit der höchsten CPU-Nutzung der vorherigen Stunde zurück:

SELECT text,
       request_tag,
       execution_count AS count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY total_cpu DESC;

Gesamtzahl der Ausführungen in einem bestimmten Zeitraum ermitteln

Die folgende Abfrage gibt die Gesamtzahl der im letzten vollständigen 1-Minuten-Intervall ausgeführten Abfragen zurück:

SELECT interval_end,
       execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_minute);

Durchschnittliche Latenz für eine Abfrage ermitteln

Die folgende Abfrage gibt die durchschnittliche Latenzzeit für eine bestimmte Abfrage zurück:

SELECT avg_latency_seconds
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "SELECT x FROM table WHERE x=@foo;";

99. Perzentil der Latenz für Abfragen ermitteln

Durch den Vergleich der durchschnittlichen Latenz mit der Latenz des 99. Perzentils können Sie mögliche Ausreißerabfragen mit hohen Ausführungszeiten identifizieren.

Die folgenden Abfragen geben das 99. Perzentil der Ausführungszeit für Abfragen zurück, die in den letzten 10 Minuten ausgeführt wurden.

Für Datenbanken im GoogleSQL-Dialekt können Sie die Spalte LATENCY_DISTRIBUTION verwenden:

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

Für Datenbanken im PostgreSQL-Dialekt verwenden Sie stattdessen die Spalte LATENCY_DISTRIBUTION_JSON_STRING:

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution_json_string, 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

Abfragen finden, die die meisten Daten scannen

Sie können die Anzahl der von einer Abfrage gescannten Zeilen als Maß für die Datenmenge verwenden, die von der Abfrage gescannt wurde. Die folgende Abfrage gibt die Anzahl der Zeilen zurück, die von Abfragen gescannt wurden, die in der vorherigen Stunde ausgeführt wurden:

SELECT text,
       execution_count,
       avg_rows_scanned
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_scanned DESC;

Anweisungen finden, mit denen die meisten Daten geschrieben wurden

Sie können die Anzahl der von DML geschriebenen Zeilen (oder Byte) als Maß für die Menge der Daten verwenden, die durch die Abfrage geändert wurden. Die folgende Abfrage gibt die Anzahl der Zeilen zurück, die von DML-Anweisungen geschrieben wurden, die in der vorherigen Stunde ausgeführt wurden:

SELECT text,
       execution_count,
       avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_written DESC;

Gesamte CPU-Nutzung für alle Abfragen

Die folgende Abfrage gibt die Anzahl der in der vorherigen Stunde verwendeten CPU-Stunden zurück:

SELECT (avg_cpu_seconds * execution_count / 60 / 60)
  AS total_cpu_hours
FROM spanner_sys.query_stats_total_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_hour);

Abfragen auflisten, die in einem bestimmten Zeitraum fehlgeschlagen sind

Die folgende Abfrage gibt die Rohdaten einschließlich der Ausführungsanzahl und der durchschnittlichen Latenz fehlgeschlagener Abfragen für die Top-Abfragen der letzten Minute zurück. Fehlgeschlagene und abgebrochene partitionierte DML-Anweisungen werden in diesen Statistiken nicht erfasst.

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       all_failed_execution_count,
       all_failed_avg_latency_seconds,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;

Gesamtzahl der Fehler in einem bestimmten Zeitraum ermitteln

Die folgende Abfrage gibt die Gesamtzahl der Abfragen zurück, die im letzten vollständigen 1-Minuten-Intervall nicht ausgeführt werden konnten. Fehlgeschlagene und abgebrochene partitionierte DML-Anweisungen werden in diesen Statistiken nicht erfasst.

SELECT interval_end,
       all_failed_execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_minute)
ORDER BY interval_end;

Abfragen mit den meisten Zeitüberschreitungen auflisten

Die folgende Abfrage gibt die Abfragen mit der höchsten Zeitüberschreitung in der vorherigen Stunde zurück.

SELECT text,
       execution_count AS count,
       timed_out_execution_count AS timeout_count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY timed_out_execution_count DESC;

Durchschnittliche Latenz erfolgreicher und fehlgeschlagener Ausführungen für eine Abfrage ermitteln

Die folgende Abfrage gibt die kombinierte durchschnittliche Latenz, die durchschnittliche Latenz für erfolgreiche Ausführungen und die durchschnittliche Latenz für fehlgeschlagene Ausführungen für eine bestimmte Abfrage zurück. Diese Statistiken erfassen keine fehlgeschlagenen und abgebrochenen partitionierten DML-Anweisungen.

SELECT avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text LIKE "select x from table where x=@foo;";

Fehlerbehebung bei hoher CPU-Auslastung oder erhöhter Abfragelatenz mit Abfragestatistiken

Abfragestatistiken sind nützlich, wenn Sie eine hohe CPU-Auslastung in Ihrer Spanner-Datenbank untersuchen müssen oder wenn Sie nur die CPU-intensiven Abfrageformen in Ihrer Datenbank verstehen möchten. Durch die Prüfung von Abfragen, die erhebliche Mengen an Datenbankressourcen verbrauchen, können Spanner-Nutzer die Betriebskosten senken und möglicherweise die allgemeinen Systemlatenzen verbessern.

Sie können SQL-Code oder das Dashboard Query Insights verwenden, um problematische Abfragen in Ihrer Datenbank zu untersuchen. In den folgenden Abschnitten wird beschrieben, wie Sie solche Abfragen mithilfe von SQL-Code untersuchen können.

Im folgenden Beispiel geht es um die CPU-Auslastung. Sie können aber ähnliche Schritte ausführen, um Probleme mit erhöhter Abfragelatenz zu beheben und die Abfragen mit den höchsten Latenzen zu finden. Wählen Sie Zeitintervalle und Abfragen nach Latenz statt nach CPU-Nutzung aus.

Wählen Sie einen Zeitraum aus, den Sie untersuchen möchten.

Starten Sie die Prüfung mit der Suche nach einem Zeitpunkt, an dem Ihre Anwendung begann, eine hohe CPU-Auslastung zu verzeichnen. Beispiel: Das Problem ist am 24. Juli 2020 um 17:00 Uhr UTC aufgetreten.

Abfragestatistiken für den ausgewählten Zeitraum erfassen

Nachdem Sie einen Zeitraum für die Untersuchung ausgewählt haben, sehen Sie sich die Statistiken an, die in der Tabelle QUERY_STATS_TOTAL_10MINUTE für diesen Zeitraum erfasst wurden. Die Ergebnisse dieser Abfrage können Aufschluss darüber geben, wie sich die CPU- und andere Abfragestatistiken in diesem Zeitraum geändert haben.

Die folgende Abfrage gibt die zusammengefassten Abfragestatistiken von 16:30 bis einschließlich 17:30 UTC zurück. In der Abfrage wird ROUND verwendet, um die Anzahl der Dezimalstellen für die Anzeige zu beschränken.

SELECT interval_end,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_rows,2) AS rows_returned,
       ROUND(avg_bytes,2) AS bytes,
       ROUND(avg_rows_scanned,2) AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS avg_cpu
FROM spanner_sys.query_stats_total_10minute
WHERE
  interval_end >= "2020-07-24T16:30:00Z"
  AND interval_end <= "2020-07-24T17:30:00Z"
ORDER BY interval_end;

Die Abfrage liefert folgende Ergebnisse.

interval_end count Latenz rows_returned Byte rows_scanned avg_cpu
2020-07-24T16:30:00Z 6 0,06 5,00 536,00 16,67 0,035
2020-07-24T16:40:00Z 55 0,02 0.22 25,29 0.22 0,004
2020-07-24T16:50:00Z 102 0,02 0,30 33,35 0,30 0,004
2020-07-24T17:00:00Z 154 1.06 4.42 486.33 7792208.12 4.633
2020-07-24T17:10:00Z 94 0,02 1,68 106,84 1,68 0,006
2020-07-24T17:20:00Z 110 0,02 0,38 34,60 0,38 0,005
2020-07-24T17:30:00Z 47 0,02 0.23 24,96 0.23 0,004

In der vorherigen Tabelle ist die durchschnittliche CPU-Zeit, die Spalte avg_cpu in der Ergebnistabelle, in den hervorgehobenen Intervallen, die um 17:00 Uhr enden, am höchsten. Außerdem ist die durchschnittliche Anzahl der gescannten Zeilen viel höher. Dies zeigt an, dass teurere Abfragen zwischen 16:50 und 17:00 Uhr ausgeführt wurden. Wählen Sie dieses Intervall aus, um es im nächsten Schritt genauer zu untersuchen.

Abfragen mit hoher CPU-Auslastung finden

Nachdem Sie ein Zeitintervall für die Untersuchung ausgewählt haben, fragen Sie die Tabelle QUERY_STATS_TOP_10MINUTE ab. Die Ergebnisse dieser Abfrage können dabei helfen, zu erkennen, welche Abfragen eine hohe CPU-Auslastung verursachen.

SELECT text_fingerprint AS fingerprint,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_cpu_seconds,3) AS cpu,
       ROUND(execution_count * avg_cpu_seconds,3) AS total_cpu
FROM spanner_sys.query_stats_top_10minute
WHERE
  interval_end = "2020-07-24T17:00:00Z"
ORDER BY total_cpu DESC;

Die Abfrage liefert folgende Ergebnisse.

Fingerprint count Latenz CPU total_cpu
5505124206529314852 30 3.88 17.635 529.039
1697951036096498470 10 4.49 18.388 183.882
2295109096748351518 1 0,33 0,048 0,048
11618299167612903606 1 0,25 0,021 0,021
10302798842433860499 1 0,04 0,006 0,006
123771704548746223 1 0,04 0,006 0,006
4216063638051261350 1 0,04 0,006 0,006
3654744714919476398 1 0,04 0,006 0,006
2999453161628434990 1 0,04 0,006 0,006
823179738756093706 1 0,02 0,005 0.0056

Die beiden wichtigsten Abfragen, die in der Ergebnistabelle hervorgehoben sind, sind Ausreißer in Bezug auf durchschnittliche CPU- und Latenz sowie Anzahl der Ausführungen und Gesamt-CPU. Sehen Sie sich die erste Abfrage in diesen Ergebnissen an.

Abfrageausführungen im Zeitverlauf vergleichen

Nachdem Sie die Untersuchung eingegrenzt haben, prüfen Sie die Tabelle QUERY_STATS_TOP_MINUTE. Wenn Sie Ausführungen für eine bestimmte Abfrage im Zeitverlauf vergleichen, können Sie nach Korrelationen zwischen der Anzahl der zurückgegebenen Zeilen oder Byte oder der Anzahl der gescannten Zeilen und einer erhöhten CPU-Auslastung oder Latenz suchen. Eine Abweichung kann auf eine Ungleichförmigkeit in den Daten hinweisen. Eine konstant hohe Anzahl von gescannten Zeilen kann auf das Fehlen der entsprechenden Indexe oder der nicht optimalen Join-Reihenfolge hinweisen.

Untersuchen Sie die Abfrage mit der höchsten durchschnittlichen CPU-Auslastung und der höchsten Latenz, indem Sie die folgende Anweisung ausführen, die nach dem text_fingerprint dieser Abfrage filtert.

SELECT interval_end,
       ROUND(avg_latency_seconds,2) AS latency,
       avg_rows AS rows_returned,
       avg_bytes AS bytes_returned,
       avg_rows_scanned AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS cpu,
FROM spanner_sys.query_stats_top_minute
WHERE text_fingerprint = 5505124206529314852
ORDER BY interval_end DESC;

Die Abfrage liefert folgende Ergebnisse.

interval_end Latenz rows_returned bytes_returned rows_scanned CPU
2020-07-24T17:00:00Z 4.55 21 2365 30000000 19.255
2020-07-24T16:00:00Z 3,62 21 2365 30000000 17,255
2020-07-24T15:00:00Z 4,37 21 2365 30000000 18,350
2020-07-24T14:00:00Z 4,02 21 2365 30000000 17,748
2020-07-24T13:00:00Z 3.12 21 2365 30000000 16,380
2020-07-24T12:00:00Z 3,45 21 2365 30000000 15,476
2020-07-24T11:00:00Z 4,94 21 2365 30000000 22,611
2020-07-24T10:00:00Z 6,48 21 2365 30000000 21,265
2020-07-24T09:00:00Z 0.23 21 2365 5 0,040
2020-07-24T08:00:00Z 0,04 21 2365 5 0,021
2020-07-24T07:00:00Z 0,09 21 2365 5 0,030

Wenn Sie sich die vorherigen Ergebnisse ansehen, werden Sie feststellen, dass sich die Anzahl der gescannten Zeilen, die CPU-Auslastung und die Latenz gegen 9:00 Uhr deutlich geändert haben. Um zu verstehen, warum diese Zahlen so stark gestiegen sind, sehen Sie sich den Abfragetext an und prüfen Sie, ob sich Änderungen am Schema auf die Abfrage ausgewirkt haben könnten.

Verwenden Sie die folgende Abfrage, um den Abfragetext für die Abfrage abzurufen, die Sie untersuchen.

SELECT text,
       text_truncated
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852
LIMIT 1;

Dies gibt das folgende Ergebnis zurück.

text text_truncated
select * aus Bestellungen mit o_custkey = 36901; falsch

Wenn Sie sich den zurückgegebenen Abfragetext ansehen, werden Sie feststellen, dass die Abfrage nach einem Feld namens o_custkey filtert. Dies ist eine Nicht-Schlüsselspalte in der Tabelle orders. In diesem Fall war bis zu 9:00 Uhr ein Index für diese Spalte vorhanden. Dies erklärt die Änderung der Kosten für diese Abfrage. Sie können den Index wieder hinzufügen oder, wenn die Abfrage selten ausgeführt wird, auf den Index verzichten und die höheren Lesekosten akzeptieren.

Die Untersuchung konzentrierte sich bisher auf Abfragen, die erfolgreich abgeschlossen wurden, und hat einen Grund für die Leistungseinbußen der Datenbank ermittelt. Konzentrieren Sie sich im nächsten Schritt auf fehlgeschlagene oder abgebrochene Abfragen und untersuchen Sie diese Daten, um weitere Informationen zu erhalten.

Fehlgeschlagene Abfragen untersuchen

Abfragen, die nicht erfolgreich abgeschlossen werden, verbrauchen weiterhin Ressourcen, bevor sie das Zeitlimit überschreiten, abgebrochen werden oder anderweitig fehlschlagen. Cloud Spanner erfasst die Anzahl der Ausführungen und die von fehlgeschlagenen Abfragen verbrauchten Ressourcen zusammen mit den erfolgreichen Abfragen. Diese Statistiken erfassen keine fehlgeschlagenen und abgebrochenen partitionierten DML-Anweisungen.

Wenn Sie prüfen möchten, ob fehlgeschlagene Abfragen einen wesentlichen Beitrag zur Systemauslastung leisten, prüfen Sie zuerst, wie viele Abfragen im gewünschten Zeitintervall fehlgeschlagen sind.

SELECT interval_end,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS latency
FROM spanner_sys.query_stats_total_minute
WHERE
  interval_end >= "2020-07-24T16:50:00Z"
  AND interval_end <= "2020-07-24T17:00:00Z"
ORDER BY interval_end;
interval_end failed_count Latenz
2020-07-24T16:52:00Z 1 15,211391
2020-07-24T16:53:00Z 3 58,312232

Suchen Sie mit der folgenden Abfrage nach Abfragen, die am wahrscheinlichsten fehlschlagen.

SELECT interval_end,
       text_fingerprint,
       execution_count,
       avg_latency_seconds AS avg_latency,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS failed_latency,
       cancelled_or_disconnected_execution_count AS cancel_count,
       timed_out_execution_count AS to_count
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;
interval_end text_fingerprint execution_count failed_count cancel_count to_count
2020-07-24T16:52:00Z 5505124206529314852 3 1 1 0
2020-07-24T16:53:00Z 1697951036096498470 2 1 1 0
2020-07-24T16:53:00Z 5505124206529314852 5 2 1 1

Wie die vorherige Tabelle zeigt, ist die Abfrage mit dem Fingerabdruck 5505124206529314852 in verschiedenen Zeitintervallen mehrmals fehlgeschlagen. Angesichts eines solchen Ausfallmusters ist es interessant, die Latenz erfolgreicher und fehlgeschlagener Ausführungen zu vergleichen.

SELECT interval_end,
       avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text_fingerprint = 5505124206529314852;
interval_end combined_avg_latency failed_execution_latency success_execution_latency
2020-07-24T17:00:00Z 3,880420 13,830709 2,774832

Best Practices anwenden

Nachdem Sie eine Abfrage für die Optimierung identifiziert haben, sehen Sie sich als Nächstes das Abfrageprofil an und versuchen Sie, die Abfrage mithilfe von Best Practices für SQL zu optimieren.

Nächste Schritte