Fehlerbehebung bei Leistungseinbußen bei Abfragen

Auf dieser Seite wird erläutert, wie Sie Änderungen bei der Geschwindigkeit der Abfrageausführung erkennen, Abfrageausführungspläne prüfen und bei Bedarf einen anderen Index für zukünftige Abfragen angeben.

Mit der REST API das detaillierte Profil einer Abfrage im JSON-Format abrufen

Wenn Sie eine Abfrage ausführen, gibt die API standardmäßig nur die Ergebnisse der Anweisung zurück. Das liegt daran, dass queryMode auf NORMAL festgelegt ist. Wenn Sie detaillierte Ausführungsstatistiken in die Abfrageergebnisse aufnehmen möchten, setzen Sie queryMode auf PROFILE.

Sitzung erstellen

Bevor Sie den Abfragemodus aktualisieren, erstellen Sie eine Sitzung, die einen Kommunikationskanal mit dem Spanner-Datenbankdienst darstellt.

  1. Rufen Sie die Seite projects.instances.databases.sessions.create auf.
  2. Geben Sie die Projekt-ID, die Instanz-ID und die Datenbank-ID im folgenden Format an:

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID

  3. Klicken Sie auf Ausführen. Die Antwort enthält die erstellte Sitzung in der folgenden Form:

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID/sessions/SESSION_ID

    Verwenden Sie diese Sitzung, um die Abfrage im nächsten Schritt zu profilieren. Eine Sitzung bleibt zwischen aufeinanderfolgenden Verwendungen bis zu einer Stunde aktiv, bevor sie von Spanner gelöscht wird.

Weitere Informationen zur Verwendung von Sitzungen finden Sie unter Sitzungen.

Abfrage profilieren

Aktivieren Sie den Modus PROFILE für die Abfrage.

  1. Rufen Sie die Seite projects.instances.databases.sessions.executeSql auf.
  2. Geben Sie für Sitzung die Sitzungs-ID ein, die Sie unter Sitzung erstellen erstellt haben:

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID/sessions/SESSION_ID

  3. Verwenden Sie Folgendes für Request body (Anfragetext):

    { "sql": "SQL_QUERY", "queryMode": "PROFILE" }

  4. Klicken Sie auf Ausführen. Die Antwort enthält die Abfrageergebnisse, den Abfrageplan und die Ausführungsstatistiken für die Abfrage.

Fehler bei der Indexnutzung beheben

Wenn Sie SQL-Abfragen zum Suchen von Daten verwenden, verwendet Spanner automatisch alle sekundären Indexe, mit denen die Daten wahrscheinlich effizienter abgerufen werden können. In einigen Fällen wählt Spanner jedoch einen Index aus, der die Abfragen verlangsamt. Daher kann es vorkommen, dass einige Abfragen langsamer als erwartet ausgeführt werden.

Änderungen der Abfrageausführungsgeschwindigkeit erkennen

Wenn Sie eine der folgenden Änderungen vornehmen, führt dies vermutlich zu einer Änderung der Ausführungsgeschwindigkeit der Abfrage:

  • Eine große Anzahl vorhandener Daten mit einem sekundären Index wird erheblich verändert.
  • Ein sekundärer Index wird hinzugefügt, geändert oder gelöscht.

Sie können verschiedene Tools verwenden, um eine bestimmte Abfrage zu identifizieren, die von Spanner langsamer als gewöhnlich ausgeführt wird:

  • Query Insights und Abfragestatistiken.
  • Latenzmesswerte:

  • Anwendungsspezifische Messwerte, die Sie mit Cloud Monitoring erfassen und analysieren. Sie können beispielsweise den Messwert Anzahl der Abfragen überwachen, um die Anzahl der Abfragen in einer Instanz im Zeitverlauf zu ermitteln und herauszufinden, welche Version des Abfrageoptimierers zum Ausführen einer Abfrage verwendet wurde.

  • Clientseitige Monitoring-Tools zur Messung der Anwendungsleistung

Optimierungsstatistiken für neu erstellte Datenbanken

Wenn Sie neu erstellte Datenbanken mit neu eingefügten oder importierten Daten abfragen, wählt Cloud Spanner möglicherweise nicht die am besten geeigneten Indexe aus, da der Abfrageoptimierer bis zu drei Tage benötigt, um Statistiken automatisch zu erfassen. Wenn Sie die Indexnutzung einer neuen Spanner-Datenbank früher optimieren möchten, können Sie manuell ein neues Statistikpaket erstellen.

Schema prüfen

Nachdem Sie die Abfrage ermittelt haben, die langsamer ausgeführt wird, sehen Sie sich die SQL-Anweisung für die Abfrage an und identifizieren Sie die Tabellen, die die Anweisung verwendet, sowie die Spalten, die sie aus diesen Tabellen abruft.

Suchen Sie als Nächstes die sekundären Indexe für diese Tabellen. Prüfen Sie, ob einer der Indexe die Spalten enthält, die Sie abfragen. Das bedeutet, dass Spanner möglicherweise einen der Indexe zum Verarbeiten der Abfrage verwendet.

  • Wenn anwendbare Indexe vorhanden sind, müssen Sie im nächsten Schritt den Index finden, den Spanner für die Abfrage verwendet hat.
  • Wenn keine anwendbaren Indexe vorhanden sind, prüfen Sie mit dem Befehl gcloud spanner operations list, ob Sie vor Kurzem einen anwendbaren Index gelöscht haben:

    gcloud spanner operations list \
        --instance=INSTANCE \
        --database=DATABASE \
        --filter="@TYPE:UpdateDatabaseDdlMetadata"
    

    Wenn Sie einen anwendbaren Index gelöscht haben, hat dies möglicherweise die Abfrageleistung negativ beeinflusst. Fügen Sie den sekundären Index dann wieder zur Tabelle hinzu. Nachdem Spanner den Index hinzugefügt hat, führen Sie die Abfrage noch einmal aus und sehen Sie sich die Leistung an. Wenn sich die Leistung nicht verbessert, besteht der nächste Schritt darin, den Index zu finden, den Spanner für die Abfrage verwendet hat.

    Wenn Sie keinen anwendbaren Index gelöscht haben, war die Indexauswahl nicht für den Rückgang der Abfrageleistung verantwortlich. Prüfen Sie dann eventuelle andere Änderungen an Ihren Daten oder Nutzungsmustern, die sich möglicherweise auf die Leistung ausgewirkt haben.

Für eine Abfrage verwendeten Index finden

Wenn Sie herausfinden möchten, welchen Index Spanner zum Verarbeiten einer Abfrage verwendet, rufen Sie den Abfrageausführungsplan in der Google Cloud Console auf:

  1. Rufen Sie in derGoogle Cloud Console die Spanner-Seite Instanzen auf.

    Zur Seite "VM-Instanzen"

  2. Klicken Sie auf den Namen der Instanz, die Sie abfragen möchten.

  3. Wählen Sie im Navigationsmenü die Datenbank aus, die Sie abfragen möchten, und klicken Sie dann auf Spanner Studio.

  4. Geben Sie die Abfrage ein, die geprüft werden soll.

  5. Wählen Sie im Menü Abfrage ausführen die Option Nur Erklärung aus. Cloud Spanner zeigt den Abfrageplan an.

Suchen Sie im Abfrageplan nach mindestens einem der folgenden Operatoren:

  • Table Scan
  • Index Scan
  • Cross Apply oder Distributed Cross Apply

Die Bedeutung der einzelnen Operatoren wird in den folgenden Abschnitten erläutert.

Operator "Table Scan"

Der Operator Tabellenscan gibt an, dass Spanner keinen sekundären Index verwendet hat:

Tabellenscan-Operator in einem Abfrageplan.

Angenommen, die Tabelle Albums enthält keine sekundären Indexe und Sie führen die folgende Abfrage aus:

SELECT AlbumTitle FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

Da keine verwendbaren Indexe vorhanden sind, enthält der Abfrageplan einen Operator "Table Scan".

Operator "Index Scan"

Der Operator Indexscan gibt an, dass Spanner bei der Verarbeitung der Abfrage einen sekundären Index verwendet hat:

Indexscan-Operator in einem Abfrageplan.

Angenommen, Sie fügen der Tabelle Albums einen Index hinzu:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Anschließend führen Sie die folgende Abfrage aus:

SELECT AlbumTitle FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

Der Index AlbumsByAlbumTitle enthält AlbumTitle. Dies ist die einzige Spalte, die von der Abfrage ausgewählt wird. Daher enthält der Abfrageplan einen Operator "Index Scan".

Operator "Cross Apply"

In einigen Fällen verwendet Spanner einen Index, der nur einige der Spalten enthält, die von der Abfrage ausgewählt werden. Daher muss Spanner den Index mit der Basistabelle verknüpfen.

Wenn diese Art von Join auftritt, enthält der Abfrageplan einen Cross Apply- oder Distributed Cross Apply-Operator mit den folgenden Eingaben:

  • Operator "Index Scan" für den Index einer Tabelle
  • Operator "Table Scan" für die Tabelle, zu der der Index gehört

Verteilter „Cross Apply“ in einem Abfrageplan mit einem Indexscan und einem Tabellenscan als Eingaben.

Angenommen, Sie fügen der Tabelle Albums einen Index hinzu:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Anschließend führen Sie die folgende Abfrage aus:

SELECT * FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

Der Index AlbumsByAlbumTitle enthält AlbumTitle, die Abfrage wählt aber alle Spalten in der Tabelle aus, nicht nur AlbumTitle. Daher enthält der Abfrageplan den Operator "Distributed Cross Apply" mit einem "Index Scan" von AlbumsByAlbumTitle und einem "Table Scan" von Albums als Eingaben.

Anderen Index auswählen

Nachdem Sie den Index gefunden haben, den Spanner für Ihre Abfrage verwendet hat, versuchen Sie, die Abfrage mit einem anderen Index auszuführen oder die Basistabelle zu scannen, anstatt einen Index zu verwenden. Wenn Sie den Index angeben möchten, fügen Sie eine FORCE_INDEX-Anweisung zur Abfrage hinzu.

Wenn Sie eine schnellere Version der Abfrage finden, aktualisieren Sie Ihre Anwendung, um die schnellere Version zu verwenden.

Leitlinien für die Auswahl eines Index

Mithilfe der folgenden Leitlinien können Sie festlegen, welcher Index für die Abfrage getestet werden soll:

  • Wenn Ihre Abfrage eines dieser Kriterien erfüllt, sollten Sie die Basistabelle anstelle eines sekundären Index verwenden:

    • Die Abfrage prüft auf Übereinstimmung mit einem Präfix des Primärschlüssels der Basistabelle (z. B. SELECT * FROM Albums WHERE SingerId = 1).
    • Eine große Anzahl von Zeilen erfüllt die Abfrageprädikate (z. B. SELECT * FROM Albums WHERE AlbumTitle != "There Is No Album With This Title").
    • Die Abfrage verwendet eine Basistabelle, die nur einige hundert Zeilen enthält.
  • Wenn die Abfrage ein sehr selektives Prädikat enthält (z. B. REGEXP_CONTAINS, STARTS_WITH, <, <=, >, >= oder !=), versuchen Sie, einen Index zu verwenden, der dieselben Spalten enthält, die Sie im Prädikat verwenden.

Aktualisierte Abfrage testen

Verwenden Sie die Google Cloud Console, um die aktualisierte Abfrage zu testen und herauszufinden, wie lange die Verarbeitung der Abfrage dauert.

Wenn Ihre Abfrage Abfrageparameter enthält und ein Abfrageparameter sehr viel häufiger an einige Werte gebunden ist als andere, binden Sie den Abfrageparameter mit einem dieser Werte in Ihre Tests ein. Beispiel: Wenn die Abfrage ein Prädikat wie z. B. WHERE country = @countryId enthält und fast alle Ihre Abfragen @countryId an den Wert US binden, dann binden Sie für Ihre Leistungstests @countryId an US. Ein solches Vorgehen hilft Ihnen bei der Optimierung der Abfragen, die Sie am häufigsten ausführen.

So testen Sie die aktualisierte Abfrage in der Google Cloud Console:

  1. Rufen Sie in derGoogle Cloud Console die Spanner-Seite Instanzen auf.

    Zur Seite "VM-Instanzen"

  2. Klicken Sie auf den Namen der Instanz, die Sie abfragen möchten.

  3. Klicken Sie im Navigationsmenü auf die Datenbank, die Sie abfragen möchten, und dann auf Spanner Studio.

  4. Geben Sie die Abfrage ein, die getestet werden soll, einschließlich der Anweisung FORCE_INDEX und klicken Sie auf Abfrage ausführen.

    In der Google Cloud Console wird der Tab Ergebnistabelle geöffnet und die Abfrageergebnisse werden angezeigt, einschließlich der Zeit, die der Spanner-Dienst für die Verarbeitung der Abfrage benötigt hat.

    Dieser Messwert enthält keine anderen Latenzquellen, z. B. die Zeit, die die Google Cloud Console benötigt, um die Abfrageergebnisse zu interpretieren und anzuzeigen.

Abfragedrosselung

Während der Abfrageausführung kann Spanner Abfragen an mehreren Stellen drosseln.

Client-Wartezeit und Server-Warteschlangenverzögerung sind die beiden primären Messwerte für die Drosselung.

Wartezeit des Clients

Client-Wartezeit ist die Zeit, die der Spanner-Client darauf wartet, dass die Anwendung Ergebnisse verarbeitet. Dies weist darauf hin, dass der Client Ergebnisse nicht so schnell verarbeiten kann, wie Cloud Spanner sie erzeugt. Um dieses Problem zu beheben, erhöhen Sie entweder die Leistung der verbrauchenden Anwendung oder puffern Sie alle Ergebnisse in der Clientanwendung und verarbeiten Sie sie nach Abschluss der Abfrage.

Verzögerung der Serverwarteschlange

Serverwarteschlangenverzögerung tritt auf, wenn der Verarbeitungsserver die Planung der Abfrageausführung verzögert. Prüfen Sie im Bereich Abfragezusammenfassung den Messwert Serverwarteschlangenverzögerung. Wenn der Messwert nicht vorhanden ist, ist keine Serververzögerung aufgetreten.

Diese Verzögerung kann darauf hinweisen, dass die Server, die die Abfrage ausführen, überlastet sind. Informationen dazu, wie Sie prüfen, ob ein Hotspot vorhanden ist, finden Sie unter Hotspots in Ihrer Datenbank finden. Informationen zur Fehlerbehebung bei Hotspots finden Sie unter Hotspots mithilfe von Hot-Split-Statistiken beheben.

Vor Kurzem geänderte Daten

Änderungen an Tabellendaten können sich auf die Abfrageleistung auswirken.

Veraltetes Statistikpaket

Wenn der Optimierer ein veraltetes Statistikpaket verwendet, wählt er möglicherweise einen suboptimalen Plan aus. Im Abschnitt Abfragezusammenfassung können Sie das Statistikpaket prüfen. Wenn das Paket veraltet ist oder fehlt, führen Sie ANALYZE aus, um sicherzustellen, dass die Optimierungsstatistiken auf dem neuesten Stand sind.

Statistikpaket in der Abfragezusammenfassung

Weitere Informationen finden Sie unter Statistikpakete.

Änderungen am Tabelleninhalt

Die Abfrageleistung hängt von den Daten ab, die von der Abfrage verarbeitet werden. Wie Sie ein Leistungsproblem bei Abfragen am besten beheben, hängt davon ab, wie sich die Daten geändert haben:

  • Verzerrung in der Wertverteilung: Das Statistikpaket erfasst diese Verzerrung, aber das Abfrageoptimierungstool kann diese Informationen nur verwenden, wenn Sie Literalwerte in der Abfrage verwenden.
  • Große Änderung der Zeilenanzahl: Prüfen Sie, ob die Prädikate die Zeilen ausreichend filtern, wenn die Tabelle größer wird.
  • Verzerrung der Wertgröße: Eine Verzerrung der Wertgröße ist in Verbindung mit rechenintensiven skalaren Prädikaten problematisch (z. B. Ausführen eines LIKE-Prädikats für einen STRING-Wert, der große Strings enthält).

Weitere Informationen zur Abfrageausführung erhalten Sie über die REST API.