Abfragestatistiken verwenden, um die Abfrageleistung zu verbessern

Auf dieser Seite wird beschrieben, wie Sie mit dem Query Insights-Dashboard Leistungsprobleme bei Ihren Abfragen erkennen und analysieren.

Einführung

Mit Query Insights können Sie Probleme bei der Abfrageleistung in Cloud SQL-Datenbanken ermitteln, diagnostizieren und verhindern. Es unterstützt ein intuitives Monitoring und liefert Diagnoseinformationen, die Ihnen helfen, über die Erkennung hinaus die Ursache von Leistungsproblemen zu identifizieren.

Mit Query Insights können Sie die Leistung auf Anwendungsebene überwachen und die Quelle einer problematischen Abfrage im gesamten Anwendungspaket nach Modell, Ansicht, Controller, Route, Nutzer und Host verfolgen. Das Query Insights-Tool lässt sich mit offenen Standards und APIs in Ihre vorhandenen Tools zur Anwendungsüberwachung (APM) und in Google Cloud-Dienste einbinden. So können Sie Abfrageprobleme mit Ihrem Lieblingstool überwachen und beheben.

Mit Query Insights können Sie die Leistung von Cloud SQL-Abfragen verbessern. Dabei werden Sie durch die folgenden Schritte geführt:

Abfrageanalysen für Cloud SQL Enterprise Plus

Wenn Sie die Cloud SQL Enterprise Plus-Version verwenden, können Sie in Query Insights auf zusätzliche Funktionen zugreifen, um erweiterte Diagnosen zur Abfrageleistung durchzuführen. Zusätzlich zu den Standardfunktionen des Query Insights-Dashboards können Sie mit Query Insights für Cloud SQL Enterprise Plus-Version Folgendes tun:

  • Warteereignisse für alle ausgeführten Abfragen erfassen und analysieren.
  • Aggregierte Datenbanklast nach zusätzlichen Dimensionen wie Abfragen, Tags und Warteereignistypen filtern.
  • Erfassen Sie Abfragepläne für alle ausgeführten Abfragen.
  • Bis zu 200 Abfragepläne pro Minute.
  • Längere Abfragetexte mit bis zu 1 MB erfassen.
  • Messwerte werden nahezu in Echtzeit aktualisiert (innerhalb von Sekunden).
  • Messwerte länger als 30 Tage aufbewahren.
  • Indexempfehlungen vom Indexberater erhalten
  • Beenden Sie eine Sitzung oder eine lang andauernde Transaktion in aktiven Abfragen.
  • Auf die KI-gestützte Fehlerbehebung zugreifen (Vorschau)

In der folgenden Tabelle werden die funktionalen Anforderungen und Funktionen von Query Insights für die Cloud SQL Enterprise-Version mit denen von Query Insights für die Cloud SQL Enterprise Plus-Version verglichen.

Vergleichsbereich Query Insights für Cloud SQL Enterprise-Version Abfrageanalysen für Cloud SQL Enterprise Plus
Unterstützte Datenbankversionen MySQL 5.7 oder höher MySQL 8.0 oder höher
Unterstützte Maschinentypen Auf allen Maschinentypen unterstützt Wird nicht für Instanzen unterstützt, die einen Maschinentyp mit gemeinsam genutztem Kern verwenden
Unterstützte Regionen Regionale Cloud SQL-Standorte Regionale Standorte für Cloud SQL Enterprise Plus
Aufbewahrungsdauer für Messwerte 7 Tage 30 Tage
Maximale Abfragelänge 4.500 Byte 1 MB
Maximum für Abfrageplanstichproben 20 200
Analyse von Warteereignissen Nicht verfügbar Verfügbar
Empfehlungen des Indexberaters Nicht verfügbar Verfügbar
Sitzungen oder lang andauernde Transaktionen in aktiven Abfragen beenden Nicht verfügbar Verfügbar
KI-basierte Fehlerbehebung (Vorschau) Nicht verfügbar Verfügbar

Abfrageanalysen für Cloud SQL Enterprise Plus aktivieren

Wenn Sie Query Insights für die Cloud SQL Enterprise Plus-Version aktivieren möchten, wählen Sie Enterprise Plus-Funktionen aktivieren aus, wenn Sie Query Insights aktivieren.

Preise

Für Abfrageanalysen in Cloud SQL Enterprise- oder Cloud SQL Enterprise Plus-Instanzen fallen keine zusätzlichen Kosten an.

Speicherbedarf

Query Insights für Cloud SQL Enterprise belegt keinen Speicherplatz in Ihrem Cloud SQL-Instanzspeicher. Messwerte werden in Cloud Monitoring gespeichert. Informationen zu API-Anfragen finden Sie unter Cloud Monitoring-Preise. Cloud Monitoring bietet eine Stufe, die Sie ohne zusätzliche Kosten nutzen können.

Bei der Cloud SQL Enterprise Plus-Version werden Messwertdaten für Query Insights auf demselben Laufwerk gespeichert, das an Ihre Cloud SQL-Instanz angehängt ist. Außerdem muss die Einstellung für automatische Speichererweiterungen aktiviert sein.

Der Speicherbedarf für Daten von sieben Tagen beträgt etwa 45 GB. Für 30 Tage benötigen Sie etwa 180 GB. Für Query Insights für Cloud SQL Enterprise Plus werden bis zu 130 MB RAM verwendet. Messwerte sollten innerhalb einer Minute nach Abschluss der Abfrage in Query Insights verfügbar sein. Es fallen die entsprechenden Speichergebühren an.

Beschränkungen für die Speicherung von Messwerten

Für Cloud SQL Enterprise Plus-Instanzen gelten die folgenden Einschränkungen für Abfrageanalysen:

  • Wenn Ihre Instanz stark ausgelastet ist und Sie Messwertdaten im Dashboard Abfrage-Insights abfragen, kann es sein, dass Ihre Abfragen langsam geladen werden oder eine Zeitüberschreitung auftritt.
  • Wenn Sie ein Lesereplikat neu erstellen, wird der vorherige Messwertverlauf nicht beibehalten.
  • Wenn Sie eine Instanz mit einer alten Sicherung wiederherstellen, können Sie die Messwerte zwischen dem Zeitpunkt der Sicherung und dem Zeitpunkt, zu dem Sie die Instanz für Query Insights für Cloud SQL Enterprise Plus wiederherstellen, verlieren. Wenn Sie Ihre Instanz beispielsweise am 30. April mit einem Backup vom 25. April wiederherstellen, gehen möglicherweise alle Messwerte zwischen dem 25. und dem 30. April verloren.

Hinweise

Führen Sie die folgenden Schritte aus, bevor Sie Query Insights verwenden.

  1. Erforderliche Rollen und Berechtigungen hinzufügen
  2. Cloud Trace API aktivieren
  3. Wenn Sie Query Insights für Cloud SQL Enterprise Plus verwenden, muss Automatische Speichererweiterungen aktivieren für die Instanz aktiviert sein.

Erforderliche Rollen und Berechtigungen

Wenn Sie Query Insights verwenden möchten, müssen Sie eine vordefinierte Rolle zuweisen, eine benutzerdefinierte Rolle erstellen oder einem Nutzerkonto die erforderlichen IAM-Berechtigungen (Identity and Access Management) gewähren.

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, in dem sich die Cloud SQL-Instanz befindet, um die Berechtigungen zu erhalten, die Sie für den Zugriff auf historische Daten zur Ausführung von Abfragen im Dashboard „Query Insights“ benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die für den Zugriff auf historische Daten zur Abfrageausführung im Dashboard „Abfragestatistiken“ erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um im Dashboard „Abfrage-Insights“ auf Verlaufsdaten zur Abfrageausführung zuzugreifen:

  • databaseinsights.aggregatedStats.query
  • databaseinsights.timeSeries.query

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

In Database Insights können Sie Ihren Administrator beispielsweise bitten, Ihnen die vordefinierte Rolle Database Insights Viewer (roles/databaseinsights.viewer) zuzuweisen. Bitten Sie dann Ihren Administrator, Ihnen in Cloud SQL eine der folgenden vordefinierten Rollen zuzuweisen:

Cloud Trace API aktivieren

Wenn Sie Abfragepläne und ihre End-to-End-Ansichten aufrufen möchten, muss in Ihrem Google Cloud Projekt die Cloud Trace API aktiviert sein. Mit dieser Einstellung kann IhrGoogle Cloud -Projekt ohne zusätzliche Kosten Trace-Daten von authentifizierten Quellen empfangen. Anhand dieser Daten können Sie Leistungsprobleme in Ihrer Instanz erkennen und diagnostizieren.

So prüfen Sie, ob die Cloud Trace API aktiviert ist:

  1. Rufen Sie in der Google Cloud Console APIs und Dienste auf:

    Zu "APIs und Dienste"

  2. Klicken Sie auf APIs und Dienste aktivieren.
  3. Geben Sie in der Suchleiste Cloud Trace API ein.
  4. Wenn API aktiviert angezeigt wird, ist diese API aktiviert und Sie müssen nichts tun. Klicken Sie andernfalls auf Aktivieren.

Automatische Speichererhöhungen aktivieren

Wenn Sie Query Insights für Cloud SQL Enterprise Plus verwenden, muss die Instanzeinstellung zum Aktivieren automatischer Speichererweiterungen aktiviert bleiben. Standardmäßig ist diese Option für Cloud SQL-Instanzen aktiviert.

Wenn Sie diese Instanzeinstellung zuvor deaktiviert haben und Query Insights für Cloud SQL Enterprise Plus aktivieren möchten, müssen Sie zuerst automatische Speichererhöhungen wieder aktivieren. Sie können die automatische Speichererhöhung nicht deaktivieren und gleichzeitig Query Insights für die Cloud SQL Enterprise Plus-Version aktivieren.

Abfragestatistiken aktivieren

Wenn Sie Query Insights aktivieren, werden alle anderen Vorgänge vorübergehend angehalten. Zu diesen Vorgängen gehören Systemdiagnosen, Logging, Monitoring und andere Instanzvorgänge.

Console

Abfragestatistiken für eine Instanz aktivieren

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
  3. Klicken Sie in der Kachel Konfiguration auf Konfiguration bearbeiten.
  4. Maximieren Sie im Bereich Instanz anpassen den Eintrag Query Insights.
  5. Klicken Sie das Kästchen Query Insights aktivieren an.
  6. Optional: Wählen Sie zusätzliche Funktionen für Ihre Instanz aus. Einige Funktionen sind nur für die Cloud SQL Enterprise Plus-Version verfügbar.
    7. Funktion Beschreibung Cloud SQL Enterprise-Version Cloud SQL Enterprise Plus-Version
    Enterprise Plus-Funktionen aktivieren Klicken Sie dieses Kästchen an, um Query Insights für die Cloud SQL Enterprise Plus-Version zu aktivieren. Mit Query Insights für Cloud SQL Enterprise Plus können Sie Sitzungen und lang andauernde Transaktionen in aktiven Abfragen beenden. Außerdem erhalten Sie Empfehlungen vom Indexberater, um die Abfrageverarbeitung zu beschleunigen. Die Aufbewahrungsdauer für Messwertdaten wird auf 30 Tage verlängert. Empfehlungen des Index Advisor werden automatisch aktiviert, wenn Sie Query Insights für Cloud SQL Enterprise Plus aktivieren. Wenn Sie Empfehlungen für den Indexberater deaktivieren möchten, entfernen Sie das Häkchen aus diesem Kästchen. Sie müssen dieses Kästchen anklicken, um Empfehlungen des Indexberaters und die KI-gestützte Fehlerbehebung (Vorschau) zu aktivieren. Nicht verfügbar Verfügbar

    Standard: Deaktiviert
    KI-gestützte Fehlerbehebung Aktivieren Sie dieses Kästchen, um die Erkennung von Leistungsanomalien, die Ursachen- und Situationsanalyse sowie Empfehlungen zur Behebung von Problemen mit Ihren Abfragen und Ihrer Datenbank zu aktivieren. Diese Funktion befindet sich im Vorschaumodus und kann nur über die Google Cloud Console aktiviert und aufgerufen werden. Weitere Informationen finden Sie unter Mit KI-Unterstützung beobachten und Fehler beheben. Nicht verfügbar Verfügbar

    Standard: Deaktiviert
    Client-IP-Adressen speichern Aktivieren Sie dieses Kästchen, um das Speichern von Client-IP-Adressen zu aktivieren. In Cloud SQL können die IP-Adressen gespeichert werden, von denen Abfragen stammen. Sie können diese Daten gruppieren, um Messwerte dafür zu erstellen. Abfragen stammen von mehr als einem Host. Anhand der Grafiken zu Abfragen von Client-IP-Adressen können Sie die Ursache eines Problems ermitteln. Verfügbar

    Standard: Deaktiviert    		 Verfügbar

    Standard: Deaktiviert
    Anwendungstags speichern Aktivieren Sie dieses Kästchen, um die Speicherung von Anwendungstags zu aktivieren. Durch das Speichern von Anwendungstags können Sie die APIs und MVC-Routen (Model-View-Controller) bestimmen, die Anfragen stellen, und die Daten gruppieren, um sie mit Messwerten zu vergleichen. Bei dieser Option müssen Sie Abfragen mit einer bestimmten Gruppe von Tags mithilfe der Open-Source-Bibliothek für die objektrelationale Zuordnung (ORM) der sqlcommenter-Funktion kommentieren. Diese Informationen helfen Query Insights, die Ursache eines Problems und den MVC zu ermitteln, von dem das Problem stammt. Anwendungspfade unterstützen Sie beim Anwendungsmonitoring. Verfügbar

    Standard:Deaktiviert    		 Verfügbar

    Standard:Deaktiviert
    Abfragelänge anpassen Klicken Sie dieses Kästchen an, um das Limit für die Länge eines Abfragestrings anzupassen. Höhere Abfragelängen sind hilfreich für analytische Abfragen, erfordern aber auch mehr Arbeitsspeicher. Alle Abfragestrings, die das angegebene Limit überschreiten, werden in der Anzeige abgeschnitten.

    Zum Ändern des Limits für die Abfragelänge müssen Sie die Instanz neu starten. Sie können weiterhin Tags zu Abfragen hinzufügen, die die Längenbegrenzung überschreiten.     		Sie können das Limit in Byte zwischen 256 Byte und 4500 Byte festlegen.

    Standard: 1024.     		Sie können ein Limit in Byte zwischen 1 und 1048576 angeben.

    Standard: 1024 Byte (1 KB).

    Maximale Abtastrate festlegen Klicken Sie dieses Kästchen an, um die maximale Stichprobenrate festzulegen. Die Stichprobenrate ist die Anzahl der ausgeführten Abfrageplanstichproben, die pro Minute in allen Datenbanken der Instanz erfasst werden. Wenn Sie die Abtastrate erhöhen, erhalten Sie wahrscheinlich mehr Datenpunkte. Allerdings kann dies zu Leistungseinbußen führen. Wenn Sie die Stichprobenerhebung deaktivieren möchten, legen Sie den Wert auf 0 fest. Ändern Sie diesen Wert in eine Zahl zwischen 0 und 20.

    Standard: 5.     		Sie können das Maximum auf 200 erhöhen, um mehr Datenpunkte zu erhalten.

    Standard: 5.
  7. Klicken Sie auf Speichern.

Query Insights für mehrere Instanzen aktivieren

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Klicken Sie in einer beliebigen Zeile auf das Dreipunkt-Menü .
  3. Wählen Sie Abfragestatistiken aktivieren aus.
  4. Klicken Sie im Dialogfeld auf das Kästchen Query Insights für mehrere Instanzen aktivieren.
  5. Klicken Sie auf Aktivieren.
  6. Wählen Sie im nachfolgenden Dialogfeld die Instanzen aus, für die Sie Query Insights aktivieren möchten.
  7. Klicken Sie auf Query Insights aktivieren.

gcloud

Um Query Insights für eine Cloud SQL-Instanz mithilfe von gcloud zu aktivieren, führen Sie gcloud sql instances patch mit dem Flag --insights-config-query-insights-enabled so aus, nachdem Sie INSTANCE_ID durch die ID der Instanz ersetzt haben.

Wenn Sie Query Insights für eine Cloud SQL Enterprise Plus-Instanz aktivieren, werden Empfehlungen für den Index Advisor automatisch aktiviert. 

    gcloud sql instances patch INSTANCE_ID \
    --insights-config-query-insights-enabled

Verwenden Sie außerdem eines oder mehrere der folgenden optionalen Flags:

  • --insights-config-record-client-address

    Speichert die Client-IP-Adressen, von denen Abfragen stammen, und gruppiert diese Daten, um Messwerte damit auszuführen. Abfragen stammen von mehr als einem Host. Anhand der Grafiken zu Abfragen von Client-IP-Adressen können Sie die Ursache eines Problems ermitteln.

  • --insights-config-record-application-tags

    Speichert Anwendungs-Tags, die Ihnen dabei helfen, die APIs und MVC-Routen (Model-View-Controller) zu bestimmen, die Anfragen stellen, und die Daten zu gruppieren, um sie mit Messwerten zu vergleichen. Bei dieser Option müssen Abfragen mit einem bestimmten Satz von Tags kommentiert werden. Dazu können Sie die Open-Source-Bibliothek für die objektrelationale Zuordnung (ORM) der sqlcommenter-Funktion verwenden. Diese Informationen helfen Query Insights, die Ursache eines Problems und den MVC zu ermitteln, von dem das Problem stammt. Anwendungspfade unterstützen Sie beim Anwendungsmonitoring.

  • --insights-config-query-string-length

    Legt die maximale Länge der Abfragelänge fest. Höhere Abfragelängen sind hilfreich für analytische Abfragen, erfordern aber auch mehr Arbeitsspeicher. Zum Ändern der Abfragelänge müssen Sie die Instanz neu starten. Sie können weiterhin Tags zu Abfragen hinzufügen, die die Längenbegrenzung überschreiten. Bei Cloud SQL Enterprise können Sie einen Wert in Byte zwischen 256 und 4500 angeben. Die Standardlänge der Abfrage beträgt 1024 Byte. Bei Cloud SQL Enterprise Plus können Sie ein Limit in Byte zwischen 1 und 1048576 angeben. Der Standardwert ist 1024 Bytes (1 KB).

  • --query_plans_per_minute

    Standardmäßig werden in allen Datenbanken der Instanz maximal 5 ausgeführte Abfrageplanstichproben pro Minute erfasst. Wenn Sie die Stichprobenrate erhöhen, erhalten Sie wahrscheinlich mehr Datenpunkte. Allerdings kann dies zu Leistungseinbußen führen. Wenn Sie die Stichprobenerhebung deaktivieren möchten, setzen Sie diesen Wert auf 0. Bei Cloud SQL Enterprise können Sie den Wert von 0 auf 20 ändern. Bei der Cloud SQL Enterprise Plus-Version können Sie das Maximum auf bis zu 200 erhöhen, um mehr Datenpunkte zu erhalten.

Ersetzen Sie Folgendes:

  • INSIGHTS_CONFIG_QUERY_STRING_LENGTH: Die zu speichernde Länge des Abfragestrings in Byte.
  • API_TIER_STRING: Die benutzerdefinierte Instanzkonfiguration, die für die Instanz verwendet werden soll.
  • REGION: Die Region für die Instanz.
gcloud sql instances patch INSTANCE_ID \
--insights-config-query-insights-enabled \
--insights-config-query-string-length=INSIGHTS_CONFIG_QUERY_STRING_LENGTH \
--query_plans_per_minute=QUERY_PLANS_PER_MINUTE \
--insights-config-record-application-tags \
--insights-config-record-client-address \
--tier=API_TIER_STRING \
--region=REGION

REST Version 1

Rufen Sie die Methode instances.patch mit den Einstellungen für insightsConfig auf, um Query Insights für eine Cloud SQL-Instanz mithilfe der REST API zu aktivieren.

Wenn Sie Query Insights für eine Cloud SQL Enterprise Plus-Instanz aktivieren, werden Empfehlungen für den Index Advisor automatisch aktiviert.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die Projekt-ID
  • INSTANCE_ID: die Instanz-ID

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

JSON-Text anfordern:

{
  "settings" : {
     "insightsConfig" : {
       "queryInsightsEnabled" : true,
       "recordClientAddress" : true,
       "recordApplicationTags" : true,
       "queryStringLength" : 1024,
       "queryPlansPerMinute" : 20,
   }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2025-03-28T22:43:40.009Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Terraform

Wenn Sie Terraform verwenden möchten, um Query Insights für eine Cloud SQL-Instanz zu aktivieren, legen Sie das Flag query_insights_enabled auf true fest.

Wenn Sie Query Insights für eine Cloud SQL Enterprise Plus-Instanz aktivieren, werden Empfehlungen für den Index Advisor automatisch aktiviert.

Sie können auch eines oder mehrere der folgenden optionalen Flags verwenden:

  • query_string_length: Für Cloud SQL Enterprise-Version können Sie einen Wert in Byte zwischen 256 und 4500 angeben. Die Standardlänge der Abfrage beträgt 1024 Byte. Bei Cloud SQL Enterprise Plus können Sie ein Limit in Byte zwischen 1 und 1048576 angeben. Der Standardwert ist 1024 Bytes (1 KB).
  • record_application_tags: Setzen Sie den Wert auf true, wenn Sie Anwendungs-Tags aus der Abfrage aufzeichnen möchten.
  • record_client_address: Setzen Sie den Wert auf true, wenn Sie die Client-IP-Adresse erfassen möchten. Der Standardwert ist false.
  • query_plans_per_minute: Bei Cloud SQL Enterprise-Version können Sie den Wert von 0 auf 20 festlegen. Der Standardwert ist 5. Bei der Cloud SQL Enterprise Plus-Version können Sie das Maximum auf bis zu 200 erhöhen, um mehr Datenpunkte zu erhalten.

Beispiel:

  resource "google_sql_database_instance" "INSTANCE_NAME" {
  name                = "INSTANCE_NAME"
  database_version    = "MYSQL_VERSION"
  region              = "REGION"
  root_password       = "PASSWORD"
  deletion_protection = false # set to true to prevent destruction of the resource
  settings {
    tier = "DB_TIER"
    insights_config {
      query_insights_enabled  = true
      query_string_length     = 2048 # Optional
      record_application_tags = true # Optional
      record_client_address   = true # Optional
      query_plans_per_minute  = 10 # Optional
    }
  }
  }

Führen Sie die Schritte in den folgenden Abschnitten aus, um Ihre Terraform-Konfiguration auf ein Google Cloud -Projekt anzuwenden.

Cloud Shell vorbereiten

  1. Rufen Sie Cloud Shell auf.

  2. Legen Sie das Standardprojekt Google Cloud fest, auf das Sie Ihre Terraform-Konfigurationen anwenden möchten.

    Sie müssen diesen Befehl nur einmal pro Projekt und in jedem beliebigen Verzeichnis ausführen.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Umgebungsvariablen werden überschrieben, wenn Sie in der Terraform-Konfigurationsdatei explizite Werte festlegen.

Verzeichnis vorbereiten

Jede Terraform-Konfigurationsdatei muss ein eigenes Verzeichnis haben (auch als Stammmodul bezeichnet).

  1. Erstellen Sie in Cloud Shell ein Verzeichnis und eine neue Datei in diesem Verzeichnis. Der Dateiname muss die Erweiterung .tf haben, z. B. main.tf. In dieser Anleitung wird die Datei als main.tf bezeichnet. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Wenn Sie einer Anleitung folgen, können Sie den Beispielcode in jedem Abschnitt oder Schritt kopieren.

    Kopieren Sie den Beispielcode in das neu erstellte main.tf.

    Kopieren Sie optional den Code aus GitHub. Dies wird empfohlen, wenn das Terraform-Snippet Teil einer End-to-End-Lösung ist.

  3. Prüfen und ändern Sie die Beispielparameter, die auf Ihre Umgebung angewendet werden sollen.
  4. Speichern Sie die Änderungen.
  5. Initialisieren Sie Terraform. Dies ist nur einmal für jedes Verzeichnis erforderlich. 
    terraform init

    Fügen Sie optional die Option -upgrade ein, um die neueste Google-Anbieterversion zu verwenden: 

    terraform init -upgrade

Änderungen anwenden

  1. Prüfen Sie die Konfiguration und prüfen Sie, ob die Ressourcen, die Terraform erstellen oder aktualisieren wird, Ihren Erwartungen entsprechen: 
    terraform plan

    Korrigieren Sie die Konfiguration nach Bedarf.

  2. Wenden Sie die Terraform-Konfiguration an. Führen Sie dazu den folgenden Befehl aus und geben Sie yes an der Eingabeaufforderung ein: 
    terraform apply

    Warten Sie, bis Terraform die Meldung „Apply complete“ anzeigt.

  3. Öffnen Sie Ihr Google Cloud Projekt, um die Ergebnisse aufzurufen. Rufen Sie in der Google Cloud Console Ihre Ressourcen in der Benutzeroberfläche auf, um sicherzustellen, dass Terraform sie erstellt oder aktualisiert hat.

Messwerte sollten innerhalb von Minuten nach Abschluss der Abfrage in Query Insights verfügbar sein. Sehen Sie sich die Datenaufbewahrungsrichtlinie für Cloud Monitoring an.

Query Insights-Traces werden in Cloud Trace gespeichert. Sehen Sie sich die Cloud Trace-Datenaufbewahrungsrichtlinie an.

Query Insights-Dashboard ansehen

Im Query Insights-Dashboard wird die Abfragelast basierend auf von Ihnen ausgewählten Faktoren angezeigt. Die Abfragelast ist ein Maß für die Gesamtarbeit aller Abfragen in der Instanz im ausgewählten Zeitraum. Das Dashboard bietet eine Reihe von Filtern, mit denen Sie die Abfragelast anzeigen können.

So öffnen Sie das Dashboard Query Insights:

  1. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
  2. Klicken Sie im Cloud SQL-Navigationsmenü auf Query Insights oder auf der Seite Instanzübersicht auf Zu „Query Insights“ für ausführliche Informationen über Abfragen und zur Leistung.

    3. Das Dashboard Query Insights wird geöffnet. Je nachdem, ob Sie Query Insights für Cloud SQL Enterprise oder Query Insights für Cloud SQL Enterprise Plus verwenden, werden im Dashboard „Query Insights“ die folgenden Informationen zu Ihrer Instanz angezeigt:

Cloud SQL Enterprise Plus-Version

Zeigt das Query Insights-Dashboard für die Enterprise Plus-Version mit Menüs zum Filtern nach Datenbank, Nutzer und Clientadresse an. Sie können auch nach einem Zeitraum von 1 Stunde, 6 Stunden, 1 Tag oder 30 Tagen filtern oder einen benutzerdefinierten Zeitraum auswählen. In diesem Diagramm wird die Datenbanklast nach Ausführungszeit in Millisekunden für alle Abfragen über einen Zeitraum von einer Stunde dargestellt.
  • Alle Abfragen: Hier wird die Datenbanklast für alle Abfragen für den ausgewählten Zeitraum angezeigt. Jede Anfrage ist individuell farblich gekennzeichnet. Wenn Sie einen bestimmten Zeitpunkt für eine bestimmte Anfrage aufrufen möchten, bewegen Sie den Mauszeiger auf das Diagramm für die Anfrage.
  • Datenbank: Filtert die Abfragelast für eine bestimmte Datenbank oder für alle Datenbanken.
  • Nutzer: Filtert die Abfragelast aus einem bestimmten Nutzerkonto.
  • Clientadresse: Filtert die Abfragelast von einer bestimmten IP-Adresse.
  • Zeitraum: Filtert die Abfragelast nach Zeiträumen, z. B. 1 Stunde, 6 Stunden, 1 Tag, 7 Tage, 30 Tage oder einen benutzerdefinierten Bereich.
  • Warteereignistypen: Filtert die Abfragelast nach CPU- und Sperrwartenereignistypen.
  • Abfragen, Warteereignistypen, Datenbanken, Nutzer, Tags und Clientadressen: Sortieren Sie das Diagramm nach den wichtigsten Dimensionen, die am meisten zur Datenbankbelastung beitragen. Weitere Informationen finden Sie unter Datenbanklast filtern.

Cloud SQL Enterprise-Version

Zeigt das Query Insights-Dashboard mit Drop-down-Menüs für Datenbanken, Nutzer und Adressen an. Rechts neben den Drop-down-Menüs gibt es einen Filter zum Festlegen eines Zeitraums. Außerdem wird in einem Diagramm die Datenbanklast für Top-Abfragen angezeigt. Am unteren Rand des Diagramms befinden sich Auswahlfelder für die CPU-Kapazität, CPU und CPU-Wartezeit, E/A-Wartezeit und Wartezeit bei Sperrungen sowie ein Tab für Abfragen und Tags.
  • Datenbank: Filtert die Abfragelast für eine bestimmte Datenbank oder für alle Datenbanken.
  • Nutzer: Filtert die Abfragelast aus einem bestimmten Nutzerkonto.
  • Clientadresse: Filtert die Abfragelast von einer bestimmten IP-Adresse.
  • Zeitraum: Filtert die Abfragelast nach Zeiträumen, z. B. 1 Stunde, 6 Stunden, 1 Tag, 7 Tage, 30 Tage oder einen benutzerdefinierten Bereich.
  • Diagramm zur Datenbanklast: Zeigt das Diagramm zur Abfragelast anhand gefilterter Daten an.
  • CPU-Kapazität, CPU- und CPU-Wartezeit, E/A-Wartezeit und Wartezeit für Sperrungen: Die Filter werden basierend auf den von Ihnen ausgewählten Optionen geladen. Weitere Informationen zu jedem dieser Filter finden Sie unter Datenbanklast für Top-Abfragen ansehen.
  • Abfragen und Tags: Filtert die Abfragelast entweder nach einer ausgewählten Abfrage oder einem ausgewählten SQL-Abfrage-Tag. Weitere Informationen finden Sie unter Datenbanklast filtern.

Datenbanklast für alle Abfragen ansehen

Die Anzahl der Datenbankabfragen ist eine Messung der Arbeit (in CPU-Sekunden), die von den ausgeführten Abfragen in der ausgewählten Datenbank im Zeitverlauf ausgeführt wird. Bei jeder ausgeführten Abfrage wird entweder CPU-Ressourcen, E/A-Ressourcen oder Sperren von CPU-Ressourcen verwendet oder darauf gewartet. Die Datenbankabfragelast ist das Verhältnis der Zeit, die von allen innerhalb eines bestimmten Zeitfensters abgeschlossenen Abfragen benötigt wird, zur tatsächlich verstrichenen Zeit.

Das Dashboard „Query Insights“ der obersten Ebene zeigt das Diagramm Datenbanklast – alle Top-Abfragen. Mit Drop-down-Menüs im Dashboard können Sie das Diagramm für eine bestimmte Datenbank, einen bestimmten Nutzer oder eine bestimmte Kundenadresse filtern.

Cloud SQL Enterprise Plus-Version

Zeigt das Diagramm zur Datenbanklast mit einer Last für die CPU-Kapazität, die CPU und CPU-Wartezeit sowie die E/A-Wartezeit und Wartezeit nach Sperrung.

Cloud SQL Enterprise-Version

Zeigt das Diagramm zur Datenbanklast mit einer Last für die CPU-Kapazität, die CPU und CPU-Wartezeit sowie die E/A-Wartezeit und Wartezeit nach Sperrung.

Die farbigen Linien in der Grafik zeigen die Abfragelast, in Kategorien unterteilt:

  • CPU-Kapazität: Die Anzahl der CPUs, die auf der Instanz verfügbar sind.
  • CPU und CPU-Wartezeit: Das Verhältnis der Zeit, die Abfragen in einem aktiven Zustand benötigen, zur tatsächlich verstrichenen Zeit. IO- und Sperrwartet blockieren keine Abfragen, die aktiv sind. Dieser Messwert kann bedeuten, dass die Abfrage entweder die CPU verwendet oder wartet, bis der Linux-Planer den Serverprozess plant, der die Abfrage ausführt, während andere Prozesse die CPU verwenden.
  • IO Wait: Das Verhältnis der Zeit, die Abfragen auf IO warten, zur tatsächlich verstrichenen Zeit. IO Wait beinhaltet Read IO Wait und Write IO Wait. Eine Gliederung der Informationen zu IO Waits nach Sperrung können Sie in Cloud Monitoring anzeigen. Weitere Informationen finden Sie unter Cloud SQL-Messwerte.
  • Wartezeit nach Sperrung: Das Verhältnis der Zeit, die Abfragen auf Sperren warten, zur tatsächlich verstrichenen Zeit. Dies beinhaltet Wartezeiten nach Sperrung, LwLock-Wartezeiten und BufferPin-Wartezeiten nach Sperrung. Verwenden Sie Cloud Monitoring, um eine Aufschlüsselung der Informationen für Sperrungswartezeiten anzuzeigen. Weitere Informationen finden Sie unter Cloud SQL-Messwerte.

Die farbigen Linien in der Grafik zeigen die Datenbanklast nach Ausführungszeit. Sehen Sie sich die Grafik an und verwenden Sie die Filteroptionen, um diese Fragen zu untersuchen:

  • Ist die Abfragelast hoch? Ist eine Spitze oder ein Anstieg im Zeitverlauf zu sehen? Wenn keine hohe Last angezeigt wird, liegt das Problem nicht bei Ihrer Abfrage.
  • Wie lange war die Last hoch? Ist sie erst jetzt hoch oder war sie schon lange hoch? Verwenden Sie die Bereichsauswahl, um verschiedene Zeiträume auszuwählen, um herauszufinden, wie lange das Problem besteht. Vergrößern Sie die Ansicht, um ein Zeitfenster zu sehen, in dem Spitzen bei der Abfragelast beobachtet werden. Zoomen Sie heraus, um bis zu einer Woche der Zeitachse anzuzeigen.
  • Wodurch wird die hohe Last verursacht? Sie können Optionen auswählen, um die CPU-Kapazität, die CPU- und CPU-Wartezeit, die Wartezeit der Sperrung oder die E/A-Wartezeit zu untersuchen. Das Diagramm für jede dieser Optionen hat eine andere Farbe, sodass Sie leicht die Farbe mit der höchsten Last erkennen können. Die dunkelblaue Linie im Diagramm zeigt die maximale CPU-Kapazität des Systems an. Sie können die Abfragelast mit der maximalen CPU-Systemkapazität vergleichen. Anhand dieses Vergleichs können Sie erkennen, ob die CPU-Ressourcen einer Instanz erschöpft sind.
  • Welche Datenbank hat die Auslastung? Wählen Sie im Drop-down-Menü „Datenbanken“ verschiedene Datenbanken aus, um die Datenbanken mit den höchsten Lasten zu finden.
  • Verursachen bestimmte Nutzer oder IP-Adressen eine höhere Last? Wählen Sie in den Drop-down-Menüs verschiedene Nutzer und Adressen aus, um zu identifizieren, welche die höchste Last verursachen.

Datenbanklast filtern

Sie können die Datenbanklast nach Abfragen oder Tags filtern. Wenn Sie Query Insights für Cloud SQL Enterprise Plus verwenden, können Sie das Diagramm zur Datenbanklast anpassen, um die angezeigten Daten anhand einer der folgenden Dimensionen aufzuschlüsseln:

  • Alle Abfragen

  • Warteereignistypen

  • Datenbanken

  • Nutzer

  • Tags

  • Clientadressen

Wenn Sie das Diagramm zur Datenbanklast anpassen möchten, wählen Sie im Drop-down-Menü Datenbanklast nach Ausführungszeit eine Dimension aus.

Top-Beiträge zur Datenbanklast ansehen

In der Tabelle Top-Dimensionen nach Datenbanklast sehen Sie die wichtigsten Faktoren für die Datenbanklast. In der Tabelle Top-Dimensionen nach Datenbanklast werden die wichtigsten Faktoren für den Zeitraum und die Dimension angezeigt, die Sie im Drop-down-Menü des Diagramms Datenbanklast nach Ausführungszeit auswählen. Sie können den Zeitraum oder die Dimension ändern, um die wichtigsten Faktoren für eine andere Dimension oder einen anderen Zeitraum zu sehen.

In der Tabelle Top-Dimensionen nach Datenlast können Sie die folgenden Tabs auswählen.

Tabulatortaste Beschreibung
Abfragen In der Tabelle werden die wichtigsten normalisierten Abfragen nach Gesamtausführungszeit angezeigt. Für jede Abfrage werden die in den Spalten angezeigten Daten so aufgeführt:
  • Durchschnittliche Ausführungszeit (ms): Die durchschnittliche Zeit für die Ausführung der Abfrage.
  • Gesamtausführungszeit (ms): Die Gesamtausführungszeit der jeweiligen Abfrage.
  • Durchschnittliche zurückgegebene Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage abgerufen wurden.
  • Aufrufe: Gibt an, wie oft die Abfrage von der Anwendung aufgerufen wurde.
  • %Load by SELECTED_DIMENSION (Prozentuale Last nach SELECTED_DIMENSION): Das Liniendiagramm zeigt, wie die ausgewählte Dimension für die jeweilige Abfrage verteilt ist.
Warteereignistypen In der Tabelle wird die Liste der wichtigsten Warteereignistypen angezeigt, die im ausgewählten Zeitraum aufgetreten sind. Diese Tabelle ist nur für Abfrageanalysen für Cloud SQL Enterprise Plus verfügbar.
  • Durchschn. Zeit in Wartezustand (ms): Die durchschnittliche Zeit, die die Abfragen im jeweiligen Warteereignistyp verbracht haben.
  • Gesamtzeit in Wartezustand (ms): Die Gesamtausführungszeit, die die Abfragen für den jeweiligen Warteereignistyp benötigt haben.
  • Anzahl der Warteereignistypen: Die Anzahl der Male, die ein bestimmter Warteereignistyp im ausgewählten Zeitraum aufgetreten ist.
  • %der Last nach SELECTED_DIMENSION: Im prozentualen Liniendiagramm wird dargestellt, wie die für das Diagramm zur Datenbanklast ausgewählte Dimension für den jeweiligen Warteereignistyp verteilt ist.
Datenbanken Die Tabelle enthält eine Liste der wichtigsten Datenbanken, die zur Last im ausgewählten Zeitraum für alle ausgeführten Abfragen beigetragen haben.
  • Durchschnittliche Zeit in Datenbank (ms): Die durchschnittliche Zeit, die die Abfragen in der jeweiligen Datenbank verbracht haben.
  • Gesamtzeit in Datenbank (ms): Die Gesamtausführungszeit der Abfragen in der jeweiligen Datenbank.
  • %der Last nach SELECTED_DIMENSION: Das prozentuale Liniendiagramm zeigt, wie die für das Datenbanklastdiagramm ausgewählte Dimension auf die jeweilige Datenbank verteilt ist.
Nutzer Die Tabelle enthält die Liste der Top-Nutzer für den ausgewählten Zeitraum für alle ausgeführten Abfragen.
  • Durchschnittliche Zeit im Nutzer (ms): Die durchschnittliche Zeit, die die Anfragen für den jeweiligen Nutzer benötigt haben.
  • Gesamtzeit im Nutzer (ms): Die Gesamtausführungszeit der Abfragen im jeweiligen Nutzer.
  • %der Last nach SELECTED_DIMENSION: Das prozentuale Liniendiagramm zeigt, wie die für das Diagramm zur Datenbanklast ausgewählte Dimension auf den jeweiligen Nutzer verteilt ist.
Tags Informationen zu Tags finden Sie unter Nach Abfrage-Tags filtern.
Clientadressen Die Tabelle enthält die Liste der Top-Nutzer für den ausgewählten Zeitraum für alle ausgeführten Abfragen.
  • Gesamtzeit in Clientadresse (ms): Die Gesamtausführungszeit der Abfragen für einen bestimmten Client.
  • %Auslastung nach SELECTED_DIMENSION: Das Liniendiagramm mit Prozentangaben zeigt, wie die für das Diagramm zur Datenbanklast ausgewählte Dimension auf den jeweiligen Client verteilt ist.

Nach Abfragen filtern

Die Tabelle Top-Abfragen bietet einen Überblick über die Abfragen, die die meisten Abfragelasten verursachen. Die Tabelle enthält alle normalisierten Abfragen für den Zeitraum und die Optionen, die im Query Insights-Dashboard ausgewählt wurden. Es sortiert Abfragen nach der gesamten Ausführungszeit während des ausgewählten Zeitraums.

Cloud SQL Enterprise Plus-Version

Wählen Sie eine Spaltenüberschrift aus, um die Tabelle zu sortieren.

Zeigt das Diagramm für die Datenbanklast mit einer Last für Abfragen an, wobei die Filter für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung ausgewählt sind.

Cloud SQL Enterprise-Version

Wählen Sie zum Sortieren der Tabelle eine Spaltenüberschrift oder ein Attribut aus Abfragen filtern aus.

Zeigt das Diagramm für die Datenbanklast mit einer Last für Abfragen an, wobei die Filter für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung ausgewählt sind.

Die Tabelle enthält die folgenden Attribute:

  • Abfrage: Der normalisierte Abfragestring. Standardmäßig werden in Query Insights nur 1.024 Zeichen im Abfragestring angezeigt. Abfragen mit dem Label UTILITY COMMAND enthalten in der Regel die Befehle BEGIN, COMMIT und EXPLAIN oder Wrapper-Befehle.
  • Datenbank: Die Datenbank, für die die Abfrage ausgeführt wurde.
  • Empfehlungen: Die vorgeschlagenen Empfehlungen, z. B. Indexe erstellen, um die Abfrageleistung zu verbessern.
  • Last nach Gesamtzeit/Last nach CPU/Last nach E/A-Wartezeit/Last nach Wartezeit der Sperrung: Die Optionen, mit denen Sie bestimmte Abfragen filtern können, um die größte Last zu ermitteln.
  • % der Last nach Abfragen: Der Prozentsatz der Last nach einzelnen Abfragen.
  • Latenz analysieren: Wenn Sie für diese Instanz die KI-gestützte Fehlerbehebung (Vorschau) aktiviert haben, können Sie auf diesen Link klicken, um langsame Abfragen zu beheben.
  • Durchschnittliche Ausführungszeit (ms): Die durchschnittliche Zeit für die Ausführung der Abfrage.
  • Aufrufe: Gibt an, wie oft die Anwendung die Abfrage aufgerufen hat.
  • Durchschnittliche zurückgegebene Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage zurückgegeben wurden.
  • Durchschnittlich gescannte Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage gescannt wurden.

In Query Insights werden nur normalisierte Abfragen gespeichert und angezeigt.

Standardmäßig erfasst Query Insights keine IP-Adressen oder Tag-Informationen. Sie können Query Insights aktivieren, um diese Informationen zu erfassen, und bei Bedarf die Erfassung deaktivieren.

Traces des Abfrageplans erfassen oder speichern keine konstanten Werte und entfernen keine personenidentifizierbaren Informationen, die die Konstante anzeigen kann.

Query Insights zeigt normalisierte Abfragen an – ? ersetzt also den Wert der Literalkonstante. Im folgenden Beispiel wird die Namenskonstante entfernt und durch ? ersetzt.

  UPDATE
    "demo_customer"
  SET
    "customer_id" = ?::uuid,
    "name" = ?,
    "address" = ?,
    "rating" = ?,
    "balance" = ?,
    "current_city" = ?,
    "current_location" = ?
  WHERE
    "demo_customer"."id" = ?

Nach Abfrage-Tags filtern

Zur Behebung von Fehlern in Anwendungen müssen Sie zuerst Tags zu SQL-Abfragen hinzufügen. Abfragelasttags ermöglichen eine Aufschlüsselung der Abfragelast des ausgewählten Tags im Zeitverlauf.

Query Insights bietet anwendungsorientiertes Monitoring zur Diagnose von Leistungsproblemen für Anwendungen, die mit ORMs erstellt wurden. Wenn Sie für das gesamte Anwendungspaket verantwortlich sind, können Sie mit Query Insights Abfragen in einer Anwendungsansicht verfolgen. Mit der Tag-Kennzeichnung von Abfragen können Sie Probleme auf übergeordneten Konstrukten finden, z. B. mit der Geschäftslogik oder einem Mikrodienst.

Sie können Abfragen nach der Geschäftslogik taggen, z. B. mithilfe der Tags für Zahlungen, Inventar, Geschäftsanalysen oder Versand. Anschließend können Sie die Abfragelast ermitteln, die die verschiedenen Geschäftslogik erstellt haben. Dabei kann es sich beispielsweise um unerwartete Ereignisse wie Spitzen bei den Geschäftsanalyse-Tags um 13:00 Uhr oder abnormales Wachstum bei einem Trend zur Zahlungsbearbeitung in der letzten Woche handeln.

Zur Berechnung der Datenbanklast für Tag verwendet Query Insights die Zeit, die jede Abfrage mit dem von Ihnen ausgewählten Tag benötigt. Das Tool berechnet die Abschlusszeit an der Minutengrenze anhand der tatsächlich verstrichenen Zeit.

Wählen Sie im Dashboard „Query Insights“ die Option Tags aus, um die Tag-Tabelle aufzurufen. In der Tabelle werden Tags nach der Gesamtlast nach der Gesamtzeit sortiert.

Zeigt das Query Insights-Dashboard mit der Last für Tags und einer Liste von Tags an.

Sie können die Tabelle sortieren. Wählen Sie dazu unter Tags filtern ein Attribut aus oder klicken Sie auf eine Spaltenüberschrift. Die Tabelle enthält die folgenden Attribute:

  • Action, Controller, Framework, Route, Application, DB Driver: Jedes Attribut, das Sie Ihren Abfragen hinzugefügt haben, wird als Spalte angezeigt. Sie müssen mindestens eine dieser Eigenschaften hinzufügen, wenn Sie nach Tags filtern möchten.
  • Last nach Gesamtzeit/Last nach CPU/Last nach E/A-Wartezeit/Last nach Wartezeit der Sperrung: Optionen zum Filtern bestimmter Abfragen, um die größte Last für jede Option zu finden.
  • Durchschnittliche Ausführungszeit (ms): Die durchschnittliche Zeit für die Ausführung der Abfrage.
  • Durchschnittliche zurückgegebene Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage zurückgegeben wurden.
  • Durchschnittlich gescannte Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage gescannt wurden.
  • Aufrufe: Gibt an, wie oft die Anwendung die Abfrage aufgerufen hat.
  • Datenbank: Die Datenbank, für die die Abfrage ausgeführt wurde.

Abfragedetails für eine bestimmte Abfrage oder ein bestimmtes Tag ansehen

Führen Sie auf dem Tab Abfragen oder Tags Folgendes aus, um festzustellen, ob eine bestimmte Abfrage oder ein bestimmter Tag die Ursache für das Problem ist:

  1. Wenn Sie die Liste in absteigender Reihenfolge sortieren möchten, klicken Sie auf den Header Last nach Gesamtzeit.
  2. Klicken Sie auf die Abfrage oder den Tag am Anfang der Liste. Sie hat die höchste Last und benötigt mehr Zeit als die anderen.

Die Seite Abfragedetails wird geöffnet und zeigt die Details der ausgewählten Abfrage oder des ausgewählten Tags an.

Bestimmte Abfragelast prüfen

Die Seite Abfragedetails für eine ausgewählte Abfrage wird wie unten dargestellt angezeigt:

Zeigt die Datenbanklast- und Latenzdiagramme für eine bestimmte Abfrage an.

Das Diagramm Datenbanklast – bestimmte Abfrage zeigt eine Messung der Arbeit (in CPU-Sekunden) an, die Ihre normalisierte Abfrage im Zeitverlauf in der ausgewählten Abfrage ausgeführt hat. Zur Berechnung der Last wird die von normalisierten Abfragen benötigte Zeit zur tatsächlich verstrichenen Zeit verwenden. Am Anfang der Tabelle werden die ersten 1.024 Zeichen der normalisierten Abfrage angezeigt. Literale werden dabei wegen Aggregation und personenidentifizierbaren Informationen entfernt.

Zeigt das Diagramm zur Datenbanklast mit einer Last für eine bestimmte Abfrage mit ausgewählten Filtern für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung.

Wie beim Diagramm zur Gesamtzeit der Abfragen können Sie die Last für eine bestimmte Abfrage nach Datenbank, Nutzer und Clientadresse filtern. Die Abfragelast wird in CPU-Kapazität, CPU und CPU-Wartezeit, E/A-Wartezeit und Wartezeit nach Sperrung aufgeteilt.

Bestimmte getaggte Abfragelast prüfen

Das Dashboard für ein ausgewähltes Tag wird wie unten dargestellt angezeigt. Beispiel: Wenn alle Abfragen aus einer Zahlung für Mikrodienste mit dem Tag payment gekennzeichnet sind, können Sie mit dem Tag payment den Umfang der Abfragelast anzeigen lassen, die im Trend liegt.

Zeigt die Datenbanklast- und Latenzgrafiken auf der Seite für ein bestimmtes Tag an.

Das Diagramm Datenbanklast – bestimmte Tags zeigt eine Messung der Arbeit (in CPU-Sekunden) an, die Abfragen, die mit Ihren ausgewählten Tags übereinstimmen, in der ausgewählten Datenbank im Laufe der Zeit ausgeführt haben. Wie beim Diagramm zur Gesamtzeit der Abfragen können Sie die Last für eine bestimmte Abfrage nach Datenbank, Nutzer und Clientadresse filtern.

Vorgänge in einem Beispielabfrageplan prüfen

Mit einem Abfrageplan wird eine Stichprobe Ihrer Abfrage erstellt und in einzelne Vorgänge unterteilt. Die einzelnen Vorgänge in der Abfrage werden erläutert.

MySQL 5.7 bietet einen geschätzten Abfrageplan mit der EXPLAIN-Ansicht, während MySQL 8.0 und höhere Versionen einen ausgeführten Abfrageplan mit der EXPLAIN ANALYZE-Ansicht bereitstellen. Ein geschätzter Abfrageplan liefert die geschätzte Ausführungszeit einer Abfrage, während ein ausgeführter Abfrageplan Echtzeitinformationen zu jedem Ausführungsschritt der jeweiligen Abfrage bereitstellt.

Abfragepläne in MySQL 5.7 werden für die folgenden Abfragen unterstützt, die von der EXPLAIN-Anweisung unterstützt werden:

  • Für einzelne Tabellen: INSERT, SELECT, UPDATE und DELETE.
  • Für mehrere Tabellen: SELECT, UPDATE und DELETE.

Sie können Abfragepläne in MySQL 8.0 und höher für alle von EXPLAIN ANALYZE unterstützten Abfragen generieren. Dieses Tool zeigt Ihnen, wo MySQL Zeit für Ihre SELECT-Abfragen für einzelne Tabellen und mehrere Tabellen aufwendet. Cloud SQL unterstützt nicht die Generierung von DML-Abfrageplänen (Data Manipulation Language) für mehrere Tabellen, da diese Abfragen von EXPLAIN ANALYZE nicht unterstützt werden.

Der Beispielabfrageplan bietet eine EXPLAIN ANALYZE-Ansicht für die Abfrageplanstichproben, die sich auf die normalisierte Abfrage beziehen. Dies sind ausgeführte Abfragepläne, die eine Aufschlüsselung der aktiven Zeit liefern, die von jedem Vorgang im Abfrageplan benötigt wurde.

Das Diagramm Abfrageplanbeispiele zeigt alle Abfragepläne, die zu bestimmten Zeiten ausgeführt werden, sowie die Zeit, die jeder Plan benötigt hat. Sie können die Rate ändern, mit der die Stichproben von Abfrageplänen pro Minute erfasst werden. Weitere Informationen finden Sie unter Query Insights aktivieren.

Ein Diagramm für Beispielabfragepläne mit dem Ausführungszeitpunkt unten im Diagramm (x-Achse) und der Ausführungszeit in Sekunden rechts (y-Achse).

Standardmäßig zeigt das Feld rechts die Details für den Beispiel-Abfrageplan an, der die längste Zeit in Anspruch nimmt, wie im Diagramm Abfrageplan-Beispiele angezeigt. Klicken Sie auf den entsprechenden Kreis im Diagramm, um die Details für einen anderen Beispielabfrageplan anzuzeigen. Erweiterte Details zeigen ein Modell aller Vorgänge im Abfrageplan.

Jeder Vorgang zeigt die Latenz, die zurückgegebenen Zeilen und die Kosten für diesen Vorgang an. Wenn Sie einen Vorgang auswählen, werden weitere Details wie freigegebene Trefferblöcke, Schematyp, Schleifen und Planzeilen angezeigt.

Der Abfrageplan zeigt die Latenz und die Kosten für jeden Vorgang an, der für die Abfrage ausgeführt wird.

Versuchen Sie, das Problem anhand der folgenden Fragen einzugrenzen:

  1. Wie hoch ist der Ressourcenverbrauch?
  2. Wie hängt er mit anderen Abfragen zusammen?
  3. Ändert sich der Verbrauch im Laufe der Zeit?

Trace einer Beispielabfrage untersuchen

Zusätzlich zum Beispielabfrageplan können Sie mit Query Insights einen kontextbezogenen End-to-End-Anwendungs-Trace für eine Beispielabfrage aufrufen. Anhand dieses Traces können Sie die Quelle einer problematischen Abfrage ermitteln, da die Datenbankaktivität für eine bestimmte Anfrage angezeigt wird. Außerdem werden Logeinträge, die die Anwendung während der Anfrage an Cloud Logging sendet, mit dem Trace verknüpft. Das kann bei der Untersuchung hilfreich sein.

So rufen Sie den In-Context-Trace auf:

  1. Klicken Sie auf dem Bildschirm Beispielabfrage auf den Tab End-to-end-Trace. Auf diesem Tab wird ein Gantt-Diagramm mit den Zeiträumen angezeigt, die Datensätze einzelner Vorgänge für den von der Abfrage generierten Trace sind.
  2. Wenn Sie weitere Details zu den einzelnen Spans aufrufen möchten, z. B. Attribute und Metadaten, wählen Sie den entsprechenden Span aus.

Sie können sich den Trace auch auf der Seite Trace Explorer ansehen. Klicken Sie dazu auf In Cloud Trace ansehen. Weitere Informationen zur Verwendung der Seite Trace-Explorer zum Untersuchen Ihrer Tracedaten finden Sie unter Traces suchen und untersuchen.

Latenz prüfen

Latenz ist die tatsächlich verstrichene Zeit, die für den Abschluss der normalisierten Abfrage benötigt wird. Mit dem Diagramm Latenz können Sie die Latenz der Abfrage oder des Tags untersuchen. Im Latenz-Dashboard werden die Latenzen für das 50., 95. und 99. Perzentil angezeigt, um Ausreißerverhalten zu ermitteln.

Das folgende Bild zeigt das Diagramm für die Datenbanklast im 50. Perzentil für eine bestimmte Abfrage mit ausgewählten Filtern für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung an.

Zeigt das Diagramm zur Abfragelatenz für eine bestimmte Abfrage mit ausgewählten Filtern für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung an.

Die Latenz der parallelen Abfragen wird in der tatsächlich verstrichenen Zeit gemessen, obwohl die Abfragelast für die Abfrage höher sein kann, da mehrere Kerne zum Ausführen bestimmter Teile der Abfrage verwendet werden.

Versuchen Sie, das Problem anhand der folgenden Fragen einzugrenzen:

  • Wodurch wird die hohe Last verursacht? Wählen Sie Optionen aus, um die CPU-Kapazität, die CPU und CPU-Wartezeit sowie die E/A-Wartezeit und Wartezeit nach Sperrung zu sehen.
  • Wie lange war die Last hoch? Ist sie nur jetzt hoch? Oder ist sie schon lange hoch? Ändern Sie den Zeitraum, um das Datum und die Uhrzeit zu ermitteln, zu der sich die Leistung der Last verschlechterte.
  • Gibt es Latenzspitzen? Ändern Sie das Zeitfenster, um die bisherige Latenz für die normalisierte Abfrage zu untersuchen.

Tags zu SQL-Abfragen hinzufügen

Das Taggen von SQL-Abfragen vereinfacht die Fehlerbehebung in Anwendungen. Sie können sqlcommenter verwenden, um Ihren SQL-Abfragen Tags entweder automatisch oder manuell hinzuzufügen.

sqlcommenter mit ORM verwenden

Wenn Sie ORM verwenden, anstatt SQL-Abfragen direkt zu schreiben, finden Sie möglicherweise keinen Anwendungscode, der Leistungsprobleme verursacht. Unter Umständen können Sie auch nicht analysieren, wie sich Ihr Anwendungscode auf die Abfrageleistung auswirkt. Query Insights bietet eine Open-Source-Bibliothek namens sqlcommenter, um dieses Problem zu beheben. Diese Bibliothek ist für Entwickler und Administratoren nützlich, die ORM-Tools verwenden, um zu erkennen, welcher Anwendungscode Leistungsprobleme verursacht.

Wenn Sie ORM und sqlcommenter zusammen verwenden, werden die Tags automatisch erstellt. Sie müssen in der Anwendung weder Code hinzufügen noch ändern.

Sie können sqlcommenter auf dem Anwendungsserver installieren. Die Instrumentierungsbibliothek ermöglicht die Weitergabe von Anwendungsinformationen in Verbindung mit Ihrem Modell, Ihrer Ansicht und Ihrem MVC-Framework zusammen mit den Abfragen als SQL-Kommentar. Die Datenbank ruft diese Tags ab und beginnt die Aufzeichnung und Aggregation von Statistiken nach Tags. Dies sind orthogonale Statistiken mit normalisierten Abfragen. Query Insights zeigt die Tags an, damit Sie wissen, welche Anwendung die Abfragelast verursacht, und den Anwendungscode finden können, der die Leistungsprobleme verursacht.

Ergebnisse in SQL-Datenbanklogs werden so angezeigt:

    SELECT * from USERS /action='run+this',
    controller='foo%3',
    traceparent='00-01',
    tracestate='rojo%2'/

Zu den unterstützten Tags gehören der Controllername, die Route, das Framework und die Aktion.

Die Gruppe von ORM-Tools in sqlcommenter wird für die folgenden Programmiersprachen unterstützt:

Python
  • Django
  • psycopg2
  • Sqlalchemy
  • Flask
Java
  • Hibernate
  • Frühling
Ruby
  • Rails
Node.js
  • Knex.js
  • Sequelize.js
  • Express.js
PHP
  • Laravel

Weitere Informationen zu sqlcommenter und zur Verwendung in Ihrem ORM-Framework finden Sie in der sqlcommenter-Dokumentation.

Tags mit sqlcommenter hinzufügen

Wenn Sie ORM nicht verwenden, müssen Sie sqlcommenter-Tags oder Kommentare manuell im richtigen SQL-Kommentarformat zu Ihrer SQL-Abfrage hinzufügen. Außerdem müssen Sie jede SQL-Anweisung mit einem Kommentar erweitern, der ein serialisiertes Schlüssel/Wert-Paar enthält. Verwenden Sie mindestens einen der folgenden Schlüssel:

  • action=''
  • controller=''
  • framework=''
  • route=''
  • application=''
  • db driver=''

Query Insights löst alle anderen Schlüssel ab.

Query Insights deaktivieren

Console

So deaktivieren Sie Query Insights für eine Cloud SQL-Instanz mithilfe der Google Cloud -Konsole:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
  3. Klicken Sie in der Kachel Konfiguration auf Konfiguration bearbeiten.
  4. Erweitern Sie im Abschnitt Konfigurationsoptionen die Option Query Insights.
  5. Entfernen Sie das Häkchen aus dem Kästchen Query Insights aktivieren.
  6. Klicken Sie auf Speichern.

gcloud

Um Query Insights für eine Cloud SQL-Instanz mithilfe von gcloud zu deaktivieren, führen Sie gcloud sql instances patch mit dem Flag --no-insights-config-query-insights-enabled so aus, nachdem Sie INSTANCE_ID durch die ID der Instanz ersetzt haben. 

gcloud sql instances patch INSTANCE_ID \
  --no-insights-config-query-insights-enabled

REST

Rufen Sie die Methode instances.patch auf, wobei queryInsightsEnabled so auf false gesetzt ist, um Query Insights für eine Cloud SQL-Instanz mithilfe der REST API zu deaktivieren.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • instance-id: Die Instanz-ID.

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

JSON-Text anfordern:

{
  "settings" : { "insightsConfig" : { "queryInsightsEnabled" : false } }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2021-01-28T22:43:40.009Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Abfrageanalysen für Cloud SQL Enterprise Plus deaktivieren

So deaktivieren Sie Query Insights für Cloud SQL Enterprise Plus:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
  3. Klicken Sie auf Bearbeiten.
  4. Maximieren Sie im Bereich Instanz anpassen den Eintrag Query Insights.
  5. Entfernen Sie das Häkchen aus dem Kästchen Enterprise Plus-Funktionen aktivieren.
  6. Klicken Sie auf Speichern.

Nächste Schritte