Optimieren der Leistung und Standard tain-Datenbanken in Der Azure-Datenbank für MySQL – Flexibler Server mit dem sys_schema

  • Artikel

GILT FÜR: Azure Database for MySQL – Single Server Azure Database for MySQL – Flexible Server

Wichtig

Azure Database for MySQL single server is on the retirement path. Es wird dringend empfohlen, ein Upgrade auf azure Database for MySQL flexiblen Server durchzuführen. Weitere Informationen zum Migrieren zu Azure Database for MySQL flexible Server finden Sie unter Was geschieht mit Azure Database for MySQL Single Server?

Das Schema performance_schema von MySQL wurde zuerst in MySQL 5.5 eingeführt und ermöglicht die Instrumentierung für viele wichtige Serverressourcen, z.B. Speicherzuteilung, gespeicherte Programme, Metadatensperrung usw. Allerdings enthält performance_schema mehr als 80 Tabellen, und häufig erfordert das Abrufen der erforderlichen Informationen das Verknüpfen von Tabellen in performance_schema und von Tabellen aus information_schema. Basierend auf performance_schema und information_schema bietet die sys_schema eine leistungsstarke Sammlung von benutzerfreundlichen Ansichten in einer schreibgeschützten Datenbank und ist in Azure Database für MySQL flexible Server Version 5.7 vollständig aktiviert.

Views of sys_schema.

Es gibt in sys_schema 52 Sichten, die jeweils folgende Präfixe aufweisen:

  • Host_summary oder IO: Latenzen im Zusammenhang mit E/A.
  • InnoDB: InnoDB-Pufferstatus und -sperren.
  • Memory: Auslastung des Arbeitsspeichers durch Host und Benutzer.
  • Schema: Schemabezogene Informationen wie automatische Inkremente, Indizes usw.
  • Statement: Informationen zu SQL-Anweisungen, etwa Anweisungen, die vollständige Tabellenscans oder langen Abfragezeiten verursacht haben.
  • User: Belegte Ressourcen, gruppiert nach Benutzern. Beispiele sind die Datei-E/As, Verbindungen und Arbeitsspeicher.
  • Wait: Warteereignisse, gruppiert nach Host oder Benutzer.

Im Folgenden finden Sie einige allgemeine Verwendungsmuster für sys_schema. Zunächst gruppieren wir die Verwendungsmuster in zwei Kategorien: Leistungsoptimieren und Datenbankwartung.

Leistungsoptimierung

sys.user_summary_by_file_io

E/A ist der aufwendigste Vorgang in der Datenbank. Wir ermitteln die durchschnittliche E/A-Wartezeit durch Abfragen der Sicht sys.user_summary_by_file_io. Mit dem standardmäßig bereitgestellten Speicher von 125 GB beträgt die E/A-Wartezeit ca. 15 Sekunden.

IO latency: 125 GB.

Da die Azure-Datenbank für MySQL flexible Server E/A im Hinblick auf den Speicher skaliert, verringert sich die E/A-Latenz nach dem Erhöhen meines bereitgestellten Speichers auf 1 TB auf 571 ms.

IO latency: 1TB.

sys.schema_tables_with_full_table_scans

Trotz sorgfältiger Planung können viele Abfragen weiterhin zu vollständigen Tabellenscans führen. Weitere Informationen zu den Typen von Indizes und deren Optimierung finden Sie in diesem Artikel: Problembehandlung bei der Abfrageleistung. Vollständige Tabellenscans sind ressourcenintensiv und beeinträchtigen die Datenbankleistung. Die schnellste Möglichkeit zum Suchen von Tabellen mit vollständigen Tabellenscans stellt eine Abfrage der Sicht sys.schema_tables_with_full_table_scans dar.

Full table scans.

sys.user_summary_by_statement_type

Um Probleme mit der Datenbankleistung zu beheben, kann es nützlich sein, die Ereignisse, die innerhalb der Datenbank eintreten, zu ermitteln. Dazu verwenden Sie die Sicht sys.user_summary_by_statement_type.

Summary by statement.

In diesem Beispiel verbrachte azure Database for MySQL flexible Server 53 Minuten, um das langsame Abfrageprotokoll 44579 Mal zu leeren. Dies ist eine lange Zeit und bedeutet viele E/As. Sie können diese Aktivität reduzieren, indem Sie Ihr Protokoll für langsame Abfragen deaktivieren oder die Häufigkeit der Anmeldung langsamer Abfragen am Azure-Portal verringern.

Datenbankwartung

sys.innodb_buffer_stats_by_table

[!WICHTIG]

Das Abfragen dieser Ansicht kann sich auf die Leistung auswirken. Es wird empfohlen, diese Problembehandlung in ruhigeren Geschäftszeiten durchzuführen.

Der InnoDB-Pufferpool befindet sich im Arbeitsspeicher. Er ist der wichtigste Mechanismus zur Zwischenspeicherung zwischen dem DBMS und dem Speicher. Die Größe des InnoDB-Pufferpools wird durch die Leistungsstufe begrenzt und kann nur geändert werden, indem eine andere Produkt-SKU ausgewählt wird. Wie beim Arbeitsspeicher im Betriebssystem werden alte Seiten ausgelagert, um Platz für neuere Daten bereitzustellen. Um herauszufinden, welche Tabellen den meisten Speicher im InnoDB-Pufferpool belegen, können Sie die Sicht sys.innodb_buffer_stats_by_table abfragen.

InnoDB buffer status.

In der Abbildung oben wird ersichtlich, dass mit Ausnahme der Systemtabellen und -sichten alle Tabellen in der Datenbank „mysqldatabase033“, die eine WordPress-Website hostet, 16 KB oder 1 Seite der Daten im Arbeitsspeicher belegen.

Sys.schema_unused_indexes & sys.schema_redundant_indexes

Indizes sind hervorragende Tools zur Verbesserung der Leistung bei Lesevorgängen, sie verursachen jedoch zusätzliche Kosten für Einfügevorgänge und Speicher. sys.schema_unused_indexes und sys.schema_redundant_indexes geben Einblick in nicht genutzte oder doppelte Indizes.

Unused indexes.

Redundant indexes.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass sys_schema ein großartiges Tool sowohl für die Leistungsoptimierung als auch für die Datenbankwartung ist. Stellen Sie sicher, dass Sie dieses Feature in Ihrer Azure-Datenbank für flexible Serverinstanz von MySQL nutzen.

Nächste Schritte

  • Um Antworten anderer Benutzer auf häufige Fragen zu erhalten oder eine neue Frage/Antwort zu veröffentlichen, besuchen Sie Stack Overflow.