{"id":20532,"date":"2026-08-11T08:35:26","date_gmt":"2026-08-11T06:35:26","guid":{"rendered":"https:\/\/webhosting.de\/mysql-performance-schema-monitoring-tool\/"},"modified":"2026-08-11T08:35:26","modified_gmt":"2026-08-11T06:35:26","slug":"mysql-performance-schema-overvagningsvaerktoj","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/mysql-performance-schema-monitoring-tool\/","title":{"rendered":"Effektiv anvendelse af MySQL Performance Schema for at opn\u00e5 bedre ydeevne"},"content":{"rendered":"<p>F\u00fcr bessere <strong>MySQL Performance<\/strong> nutze ich das Performance Schema, um Laufzeitdaten zu Abfragen, Waits, Locks, Speicher und I\/O direkt mit SQL auszuwerten. So erkenne ich Ursachen hinter langsamen Statements schneller und leite gezielte Schritte f\u00fcr <strong>Tuning<\/strong> und Monitoring ab [2][3][15].<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n<p>Die folgenden Schwerpunkte helfen mir, das Performance Schema effektiv einzusetzen.<\/p>\n<ul>\n  <li><strong>Aktivierung<\/strong> und schlanke Konfiguration mit passenden Instrumenten und Verbrauchern<\/li>\n  <li><strong>Statement-Digests<\/strong> nutzen, um teure Muster und Hotspots zu erkennen<\/li>\n  <li><strong>Wait-Events<\/strong>, Locks und I\/O gemeinsam auswerten, um echte Engstellen zu finden<\/li>\n  <li><strong>Sys-Schema<\/strong> als Abk\u00fcrzung f\u00fcr schnelle, handlungsf\u00e4hige Einblicke<\/li>\n  <li><strong>Iterativer<\/strong> Workflow: messen, isolieren, \u00e4ndern, erneut messen<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql-performance-4041.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Performance Schema aktivieren und sinnvoll konfigurieren<\/h2>\n<p>Ich pr\u00fcfe zuerst, ob <strong>performance_schema<\/strong> aktiv ist, denn aktuelle MySQL-Versionen liefern es in der Regel eingeschaltet aus [1][12]. Fehlt es, setze ich im <code>[mysqld]<\/code>-Block der <code>my.cnf<\/code> die Variable <code>performance_schema=ON<\/code> und starte den Server neu. Danach richte ich Instrumente und Verbraucher gezielt ein, statt alles dauerhaft aufzudrehen. Ich konzentriere mich auf <code>statement\/%<\/code>, <code>wait\/%<\/code> und relevante I\/O-Pfade, damit ich aussagekr\u00e4ftige Daten ohne \u00fcberfl\u00fcssigen Overhead sammele [6]. F\u00fcr eine neue Messreihe leere ich betroffene History-Tabellen und beginne mit einer sauberen <strong>Basis<\/strong>.<\/p>\n\n<h2>Schnelle Erfolge mit dem Sys-Schema<\/h2>\n<p>F\u00fcr den schnellen \u00dcberblick greife ich oft zum <strong>sys<\/strong>-Schema, weil es die Rohdaten des Performance Schemas sinnvoll verdichtet [13]. So finde ich in Minuten die Abfragen, die den gr\u00f6\u00dften Anteil an der Laufzeit haben. Ich starte mit Top-Statements, pr\u00fcfe File-I\/O-Sichten und schaue auf Wait-Summaries f\u00fcr Threads. Sobald ich einen Hotspot erkannt habe, springe ich in die Rohtabellen zur\u00fcck und verfeinere die Analyse. Wer Abfragepl\u00e4ne nachzieht, kann mit passenden <a href=\"https:\/\/webhosting.de\/mysql-optimizer-query-hosting-optimierung-serverboost\/\">Optimizer-Tipps<\/a> h\u00e4ufig schon in kurzer Zeit sp\u00fcrbare <strong>Gewinne<\/strong> erzielen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql_performance_4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Die richtigen Instrumente und Verbraucher w\u00e4hlen<\/h2>\n<p>Ich beginne breit, halte die Beobachtung aber steuerbar: Zuerst aktiviere ich die wichtigsten <strong>Instrumente<\/strong> f\u00fcr Statements, Waits und I\/O, danach schalte ich alles aus, was kein Signal bringt [6]. Verbraucher wie Event-History und Summary-Tabellen m\u00fcssen die Fragen st\u00fctzen, die ich beantworten will. Geht es etwa um Latenzspitzen, schaue ich in <code>events_waits_summary_global_by_event_name<\/code> und vergleiche das mit <code>events_statements_summary_by_digest<\/code>. Treten I\/O-Wartezeiten auf, pr\u00fcfe ich <code>file_summary_by_event_name<\/code> und <code>table_io_waits_summary_by_table<\/code>. Diese gezielte Auswahl h\u00e4lt den Overhead klein und liefert trotzdem belastbare <strong>Daten<\/strong>.<\/p>\n\n<h2>Statement-Digests: Muster erkennen, Last senken<\/h2>\n<p>Mit Statement-Digests sehe ich, welche Muster dauerhaft teuer sind, auch wenn einzelne Abfragen variierende Literale tragen [17]. Ich sortiere nach Gesamtzeit, Ausf\u00fchrungsanzahl und durchschnittlicher Latenz, um Priorit\u00e4ten festzulegen. Dabei greife ich erg\u00e4nzend auf das <a href=\"https:\/\/webhosting.de\/mysql-slow-query-log-hosting-analysieren-queryperf\/\">Slow-Query-Log auswerten<\/a> zur\u00fcck, um seltene Ausrei\u00dfer nicht zu \u00fcbersehen. Wenn Digests Spitzen zeigen, pr\u00fcfe ich Indizes, JOIN-Strategien und Filterreihenfolgen mit <strong>EXPLAIN<\/strong>. Im Anschluss best\u00e4tige ich die Wirkung mit erneuten Messungen im Performance Schema, damit Optimierungen messbar bleiben.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql-performance-schema-tuning-4123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Warteereignisse, Locks und I\/O deuten<\/h2>\n<p>Wenn Anfragen h\u00e4ngen, befrage ich die Wait- und Lock-Tabellen, um die eigentliche <strong>Ursache<\/strong> zu finden [3]. Laufen viele Threads auf dieselben Tabellen, deuten <code>table_lock<\/code>-Waits auf Konkurrenz hin. Zeigen File-I\/O-Events hohe Latenzen, pr\u00fcfe ich Storage und Cashing sowie Abfragemuster mit gro\u00dfen Scans. Sehe ich InnoDB-Row-Locks, analysiere ich Hot-Records, Transaktionsdauer und Indexabdeckung. Erst wenn diese Puzzleteile zusammenpassen, fasse ich Server-Parameter, Schema oder Code an.<\/p>\n\n<h2>Speicherbeobachtung: Memory und Buffer-Pool<\/h2>\n<p>Speicherprobleme bremse ich, indem ich Memory-Tabellen und InnoDB-Puffer-Auslastung zusammenlese. Steigt der Speicherbedarf einzelner Komponenten, justiere ich Limits und pr\u00fcfe, ob Caches die falschen Daten binden. Reicht der InnoDB-Cache nicht, erh\u00f6he ich den Anteil oder verbessere ich die Abfrage-Lokalit\u00e4t. Wer tiefer einsteigt, kann \u00fcber <a href=\"https:\/\/webhosting.de\/mysql-buffer-pool-datenbankperformance-optimization\/\">Buffer-Pool optimieren<\/a> deutliche Latenzgewinne realisieren. Ich best\u00e4tige die Wirkung mit den <strong>Summary<\/strong>-Tabellen und verfolge, ob LRU-Hits und I\/O-Wartezeiten in die richtige Richtung laufen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/MySQL_Performance_Office_8493.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Iterativer Diagnose-Workflow f\u00fcr den Alltag<\/h2>\n<p>Ich arbeite immer in klaren Schleifen, damit ich keine Zeit verliere und Ver\u00e4nderungen messbar bleiben [3]. Zuerst reproduziere ich das Problem unter kontrollierter Last. Danach sammle ich Messwerte in wenigen, gezielten Tabellen und isoliere die auff\u00e4lligsten Kandidaten. Anschlie\u00dfend \u00e4ndere ich das, was den gr\u00f6\u00dften Nutzen verspricht: Index, Query, Parameter oder Code. Zum Schluss messe ich erneut und dokumentiere kurze <strong>Vorher\/Nachher<\/strong>-Tabellen, damit das Team die Wirkung sofort sieht.<\/p>\n\n<h2>Abfragebeispiele: Von Rohdaten zu Entscheidungen<\/h2>\n<p>F\u00fcr typische Fragen habe ich mir kompakte SQL-Snippets notiert, die ich direkt im Alltag einsetze. Die Tabelle zeigt Beispiele, die ich h\u00e4ufig nutze, und wof\u00fcr sie stehen. Ich passe Filter wie <code>LIMIT<\/code> oder <code>ORDER BY<\/code> je nach Anwendungsfall an. Wichtig bleibt: erst Hypothese, dann gezielte Auswertung und eine klare Entscheidung. So halte ich die Analyse fokussiert und vermeide \u00fcberfl\u00fcssige <strong>Last<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Performance-Schema-Tabelle(n)<\/th>\n      <th>Ziel<\/th>\n      <th>Wichtige Spalten<\/th>\n      <th>Beispiel-Query<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><code>events_statements_summary_by_digest<\/code><\/td>\n      <td>Teure Muster finden<\/td>\n      <td><code>digest_text<\/code>, <code>count_star<\/code>, <code>sum_timer_wait<\/code><\/td>\n      <td><code>SELECT digest_text, count_star, sum_timer_wait\/1e12 AS sec_total FROM performance_schema.events_statements_summary_by_digest ORDER BY sec_total DESC LIMIT 10;<\/code><\/td>\n    <\/tr>\n    <tr>\n      <td><code>events_waits_summary_global_by_event_name<\/code><\/td>\n      <td>Wait-Hotspots<\/td>\n      <td><code>event_name<\/code>, <code>sum_timer_wait<\/code><\/td>\n      <td><code>SELECT event_name, sum_timer_wait\/1e12 AS sec_total FROM performance_schema.events_waits_summary_global_by_event_name ORDER BY sec_total DESC LIMIT 10;<\/code><\/td>\n    <\/tr>\n    <tr>\n      <td><code>table_io_waits_summary_by_table<\/code><\/td>\n      <td>Tabellen-I\/O pr\u00fcfen<\/td>\n      <td><code>object_schema<\/code>, <code>object_name<\/code>, <code>read_timer_wait<\/code><\/td>\n      <td><code>SELECT object_schema, object_name, (read_timer_wait+write_timer_wait)\/1e12 AS sec_total FROM performance_schema.table_io_waits_summary_by_table ORDER BY sec_total DESC LIMIT 10;<\/code><\/td>\n    <\/tr>\n    <tr>\n      <td><code>memory_summary_global_by_event_name<\/code><\/td>\n      <td>Speicherfresser finden<\/td>\n      <td><code>event_name<\/code>, <code>current_alloc<\/code><\/td>\n      <td><code>SELECT event_name, current_alloc\/1024\/1024 AS mb FROM performance_schema.memory_summary_global_by_event_name ORDER BY mb DESC LIMIT 10;<\/code><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Produktionsbetrieb: Overhead minimieren, Wirkung maximieren<\/h2>\n<p>Im Live-Betrieb schalte ich Instrumente nicht blind an, sondern w\u00e4hle nur das, was meine Frage beantwortet [6]. Events mit hoher Frequenz behandle ich vorsichtig und halte History-Fenster kurz. F\u00fcr l\u00e4ngere Beobachtungen ziehe ich komprimierte Summaries vor und speichere Momentaufnahmen extern. Ich achte auf den Eintrag in <code>performance_schema_setup_consumers<\/code>, damit ich Sammlungen steuere statt sie laufen zu lassen. Dieser Fokus h\u00e4lt die Analyse <strong>effizient<\/strong> und sch\u00fctzt den Server.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql_perf_schema_desk_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Feinjustierung: Setup-Instrumente und -Consumer in der Praxis<\/h2>\n<p>Damit ich schnell zu belastbaren Ergebnissen komme, konfiguriere ich Instrumente und Verbraucher gezielt. Besonders wichtig sind <code>statement\/%<\/code>, <code>wait\/%<\/code>, <code>wait\/io\/%<\/code> und \u2013 bei Bedarf \u2013 ausgew\u00e4hlte <code>memory\/%<\/code>-Pfade. Ich aktiviere zun\u00e4chst nur das N\u00f6tigste und erweitere dann, wenn mir konkrete Fragen noch unbeantwortet bleiben. Die Timer im Performance Schema messen in Pikoskeunden; f\u00fcr Sekunden teile ich Latenzspalten durch <code>1e12<\/code>.<\/p>\n<p>Typischer Startpunkt zur Laufzeit:<\/p>\n<pre><code>-- Schl\u00fcssel-Instrumente anschalten\nUPDATE performance_schema.setup_instruments\n  SET ENABLED='YES', TIMED='YES'\n  WHERE NAME LIKE 'statement\/%'\n     OR NAME LIKE 'wait\/io\/%'\n     OR NAME LIKE 'wait\/lock\/%';\n\n-- Wichtige Consumer w\u00e4hlen\nUPDATE performance_schema.setup_consumers\n  SET ENABLED='YES'\n  WHERE NAME IN ('global_instrumentation',\n                 'thread_instrumentation',\n                 'statements_digest',\n                 'events_statements_current',\n                 'events_statements_history',\n                 'events_waits_current',\n                 'events_waits_history');\n\n-- F\u00fcr eine frische Messreihe Summaries leeren\nTRUNCATE TABLE performance_schema.events_statements_summary_by_digest;\nTRUNCATE TABLE performance_schema.events_waits_summary_global_by_event_name;\nTRUNCATE TABLE performance_schema.table_io_waits_summary_by_table;<\/code><\/pre>\n<p>Wenn ich Speicher-Analysen brauche, aktiviere ich selektiv <code>memory\/%<\/code>-Instrumente. Das kostet mehr Overhead, lohnt sich aber bei Leaks oder starkem Druck auf den Allocator.<\/p>\n\n<h2>Dimensionen: Benutzer, Host und Schema verstehen<\/h2>\n<p>Leistungsspitzen sind oft nicht global, sondern auf bestimmte <strong>Benutzer<\/strong>, <strong>Hosts<\/strong> oder ein <strong>Schema<\/strong> begrenzt. Das Performance Schema liefert dazu Summaries je Account und Host. Zus\u00e4tzlich enthalte ich im Digest die Spalte <code>schema_name<\/code>, um Hotspots pro Datenbank einzugrenzen.<\/p>\n<p>Beispiele, die ich h\u00e4ufig nutze:<\/p>\n<ul>\n  <li>Top-Schemata nach Gesamtlaufzeit:\n    <code>SELECT schema_name, SUM(sum_timer_wait)\/1e12 AS sec_total\nFROM performance_schema.events_statements_summary_by_digest\nGROUP BY schema_name\nORDER BY sec_total DESC\nLIMIT 10;<\/code>\n  <\/li>\n  <li>Benutzer\/Host, die die meiste Latenz verursachen (\u00fcber Accounts):\n    <code>SELECT user, host, SUM(sum_timer_wait)\/1e12 AS sec_total\nFROM performance_schema.events_statements_summary_by_account_by_event_name\nGROUP BY user, host\nORDER BY sec_total DESC\nLIMIT 10;<\/code>\n  <\/li>\n  <li>Threads mit h\u00f6chster Wartezeit:\n    <code>SELECT thread_id, SUM(sum_timer_wait)\/1e12 AS sec_total\nFROM performance_schema.events_waits_summary_by_thread_by_event_name\nGROUP BY thread_id\nORDER BY sec_total DESC\nLIMIT 10;<\/code>\n  <\/li>\n<\/ul>\n<p>Mit diesen Sichten trenne ich gezielt Trafficsegmente und kann throttlen, cachen oder Query-Varianten je Mandant einf\u00fchren.<\/p>\n\n<h2>Lange Transaktionen und Metadata-Locks sichtbar machen<\/h2>\n<p>Lange laufende oder inaktive Transaktionen blockieren Checkpoints, Purge und konkurrierende DML. Ich pr\u00fcfe deshalb regelm\u00e4\u00dfig die Transaktionssicht und MDL-Waits:<\/p>\n<ul>\n  <li>Aktive Transaktionen:\n    <code>SELECT thread_id, timer_wait\/1e12 AS sec_running, state\nFROM performance_schema.events_transactions_current\nORDER BY sec_running DESC\nLIMIT 10;<\/code>\n  <\/li>\n  <li>Metadata-Locks (DDL\/DML-Konkurrenz) erkennen:\n    <code>SELECT event_name, SUM(sum_timer_wait)\/1e12 AS sec_total\nFROM performance_schema.events_waits_summary_global_by_event_name\nWHERE event_name LIKE 'wait\/lock\/metadata\/sql\/mdl%'\nGROUP BY event_name\nORDER BY sec_total DESC;<\/code>\n  <\/li>\n<\/ul>\n<p>Wenn MDL dominiert, plane ich DDL-Fenster neu, minimiere Lock-Haltezeiten im Code (k\u00fcrzere Transaktionen) und pr\u00fcfe, ob \u00fcberfl\u00fcssige <code>AUTOCOMMIT=0<\/code>-Bl\u00f6cke Sessions unn\u00f6tig lange offen halten.<\/p>\n\n<h2>Replikation, Backups und Nebenwirkungen im Blick<\/h2>\n<p>Replikations- und Backup-Prozesse tauchen in Waits und I\/O-Sichten auf. Verz\u00f6gerungen lassen sich \u00fcber Worker-Status und Dateiwaits eingrenzen. Ich schaue auf Applier-Worker, SQL-Thread und File-I\/O-Events:<\/p>\n<ul>\n  <li>Applier-Worker mit hoher Latenz:\n    <code>SELECT worker_id, THREAD_ID, APPLYING_TRANSACTION, APPLYING_STATE\nFROM performance_schema.replication_applier_status_by_worker;<\/code>\n  <\/li>\n  <li>File-I\/O-Hotspots w\u00e4hrend Backups:\n    <code>SELECT event_name, (sum_timer_read+sum_timer_write)\/1e12 AS sec_total\nFROM performance_schema.file_summary_by_event_name\nORDER BY sec_total DESC\nLIMIT 10;<\/code>\n  <\/li>\n<\/ul>\n<p>Sehe ich hier Engp\u00e4sse, entkopple ich I\/O-Phasen (z. B. Windowing, I\/O-Scheduler, Backup-Throttling) oder erh\u00f6he parallele Applier-Worker, sofern die Workload skaliert.<\/p>\n\n<h2>Zeitfenster, Snapshots und Reset-Strategien<\/h2>\n<p>Messungen brauchen klare Zeitfenster. F\u00fcr \u201evorher\/nachher\u201c arbeite ich mit gezielten Resets und Snapshots:<\/p>\n<ul>\n  <li>Summaries zur\u00fccksetzen, um frische Intervalle zu erhalten:\n    <code>TRUNCATE TABLE performance_schema.events_statements_summary_by_digest;<\/code>\n  <\/li>\n  <li>Momentaufnahme extern sichern:\n    <code>CREATE TABLE IF NOT EXISTS perf_snapshot_digest AS\nSELECT NOW() AS captured_at, *\nFROM performance_schema.events_statements_summary_by_digest;<\/code>\n  <\/li>\n  <li>Kurze Historyfenster halten (Consumer), lange Trends extern sammeln.<\/li>\n<\/ul>\n<p>So kann ich Optimierungen \u00fcber Deployments, Parameterwechsel oder Schema\u00e4nderungen hinweg sicher vergleichen und dokumentieren.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql_perf_schema_desk_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overhead und Speicherbedarf steuern<\/h2>\n<p>Ein h\u00e4ufiges Vorurteil ist, dass das Performance Schema \u201ezu teuer\u201c sei. In der Praxis halte ich den Overhead durch drei Ma\u00dfnahmen klein: nur relevante Instrumente aktivieren, stark frequentierte History-Consumer kurz halten und die Speicherparameter passend w\u00e4hlen. Bei hoher Digest-Varianz erh\u00f6he ich gezielt <code>performance_schema_digests_size<\/code> sowie \u2013 wenn n\u00f6tig \u2013 <code>performance_schema_max_sql_text_length<\/code>, damit Identit\u00e4ten stabil bleiben. Werden Memory-Instrumente ben\u00f6tigt, begrenze ich sie auf problematische Subsysteme.<\/p>\n<p>Typische Stellschrauben in <code>my.cnf<\/code>:<\/p>\n<pre><code>[mysqld]\nperformance_schema=ON\nperformance-schema-instrument='statement\/%=ON'\nperformance-schema-instrument='wait\/io\/%=ON'\nperformance-schema-instrument='wait\/lock\/%=ON'\nperformance-schema-consumer-events-statements-history=ON\nperformance-schema-consumer-events-waits-history=ON\n# Optional, wenn viele Muster:\nperformance_schema_digests_size=10000\nperformance_schema_max_sql_text_length=4096<\/code><\/pre>\n<p>Ich messe bei jeder \u00c4nderung gegen, ob CPU, Latenz und Speichernutzung stabil bleiben. Sobald die Diagnose abgeschlossen ist, fahre ich die Konfiguration wieder auf das \u201eBetriebsminimum\u201c zur\u00fcck.<\/p>\n\n<h2>H\u00e4ufige Muster und schnelle Abhilfen<\/h2>\n<ul>\n  <li><strong>Hohe Summe in <code>events_statements_summary_by_digest<\/code>, viele Scans:<\/strong> Pr\u00fcfe Indizes, Filterreihenfolge und Sargability; best\u00e4tige mit <strong>EXPLAIN<\/strong> und wiederhole die Messung (Digest-Zeit muss sichtbar sinken).<\/li>\n  <li><strong>Dominante <code>table_io_waits<\/code> auf wenigen Tabellen:<\/strong> I\/O-Lokalisierung verbessern (Clustered Index-Zugriffe, Covering Indizes), Datenmenge pro Statement reduzieren, ggf. Batching statt Full-Table-Work.<\/li>\n  <li><strong>Wartezeiten auf <code>wait\/lock\/innodb\/%<\/code>:<\/strong> Hot-Records identifizieren, Schreibkonflikte durch kleinere Transaktionen, passende Indizes oder Queueing entsch\u00e4rfen.<\/li>\n  <li><strong>Viele <code>wait\/lock\/metadata\/sql\/mdl<\/code>:<\/strong> DDL-Fenster planen, <code>ONLINE<\/code>-f\u00e4hige Operationen bevorzugen, Reader\/Writer durch k\u00fcrzere Transaktionen entkoppeln.<\/li>\n  <li><strong>Speicheranstieg in <code>memory_summary_global_by_event_name<\/code>:<\/strong> Limits nachsch\u00e4rfen, Query-Caches gezielt begrenzen, Problemkomponenten mit <code>memory\/%<\/code> detailliert aufschl\u00fcsseln.<\/li>\n  <li><strong>\u201eSpiky\u201c Latenz bei ansonsten unauff\u00e4lligen Mittelwerten:<\/strong> Sys-Sichten mit Perzentilen einsetzen und bei Bedarf Lastspitzen separat messen (engeres Fenster, kurze History, fokussierte Instrumente).<\/li>\n<\/ul>\n\n<h2>Korrelieren: Von Thread zu Statement und Wait<\/h2>\n<p>Um Ursachen schnell zu korrelieren, verkn\u00fcpfe ich <code>performance_schema.threads<\/code> mit den Current-\/History-Tabellen f\u00fcr Statements und Waits. So sehe ich, was ein betroffener Thread zuletzt tat und worauf er wartet. Ein kompakter Ablauf:<\/p>\n<ol>\n  <li>Betroffenen <code>PROCESSLIST_ID<\/code> bzw. <code>THREAD_ID<\/code> aus <code>performance_schema.threads<\/code> holen.<\/li>\n  <li>Letztes Statement via <code>events_statements_history<\/code> ermitteln (nach <code>THREAD_ID<\/code> und Zeit sortieren).<\/li>\n  <li>Parallele Waits aus <code>events_waits_history<\/code> pr\u00fcfen, um Lock- oder I\/O-Wartegr\u00fcnde zu sehen.<\/li>\n<\/ol>\n<p>Dieses \u201eDrilldown &#038; Join\u201c-Muster ist mein Standard, wenn einzelne Sessions oder Web-Requests aus dem Takt geraten.<\/p>\n\n<h2>Quality Gates und Continuous Performance<\/h2>\n<p>Damit Optimierungen nicht verpuffen, etabliere ich schlanke Quality Gates: definierte Queries aus dem Performance Schema laufen vor und nach jedem Release. Ich sichere Snapshots weg, vergleiche Kennzahlen (Top-Digests, Top-Waits, I\/O pro Tabelle) und dokumentiere Abweichungen. In CI\/CD f\u00fcge ich repr\u00e4sentative Lastprofile und Grenzwerte f\u00fcr 95. Perzentile hinzu. F\u00e4llt eine Metrik aus dem Rahmen, gibt es einen klaren R\u00fcckkanal: Hypothese pr\u00fcfen, Instrumente fokussieren, Fix deployen, erneut messen.<\/p>\n\n<h2>Fehlerquellen vermeiden<\/h2>\n<ul>\n  <li><strong>Zu viele Instrumente auf Dauer:<\/strong> Diagnose ist tempor\u00e4r; im Regelbetrieb nur Minimalset aktiv lassen.<\/li>\n  <li><strong>Gemischte Messzeitr\u00e4ume:<\/strong> Summaries vor neuen Tests leeren, sonst verw\u00e4ssern alte Daten die Aussagekraft.<\/li>\n  <li><strong>Falsche Zeiteinheit:<\/strong> Timer sind in Pikoskeunden; konsequent durch <code>1e12<\/code> teilen.<\/li>\n  <li><strong>Digest-Flut:<\/strong> Variierende Literale k\u00f6nnen Muster sprengen; SQL normalisieren und <code>performance_schema_max_sql_text_length<\/code> pr\u00fcfen.<\/li>\n  <li><strong>History zu lang:<\/strong> Hohe Eventfrequenzen + lange History erzeugen Druck; Historyfenster kurz halten, Snapshots extern.<\/li>\n<\/ul>\n\n<h2>Praxis-Checkliste<\/h2>\n<ul>\n  <li>Frage definieren, Hypothese festhalten.<\/li>\n  <li>Passende Instrumente\/Consumer aktivieren, Overhead klein halten.<\/li>\n  <li>Summaries leeren, kurzes Messfenster w\u00e4hlen.<\/li>\n  <li>Top-Digests, Waits, I\/O pr\u00fcfen; Hotspots best\u00e4tigen.<\/li>\n  <li>Index\/Query\/Code\/Parameter gezielt anpassen.<\/li>\n  <li>Erneut messen, Snapshots sichern, Entscheidung dokumentieren.<\/li>\n  <li>Konfiguration auf Betriebsminimum zur\u00fcckfahren.<\/li>\n<\/ul>\n\n<h2>Kurz zusammengefasst: Mein Vorgehen in der Praxis<\/h2>\n<p>Ich aktiviere das Performance Schema zielgerichtet, starte breit, und reduziere dann auf die n\u00fctzlichsten <strong>Instrumente<\/strong> [1][2][12]. F\u00fcr einen schnellen \u00dcberblick ziehe ich das Sys-Schema heran und steige bei Bedarf in die Rohdaten hinab [13]. Hotspots adressiere ich zuerst bei Digests und Wait-Events, bevor ich an Parametern drehe [3][15][17]. Danach best\u00e4tige ich jede \u00c4nderung mit neuen Messungen, damit Fortschritte sichtbar und reproduzierbar bleiben. So sichere ich dauerhaft verl\u00e4ssliche <strong>Antwortzeiten<\/strong> und spare unn\u00f6tige Arbeit.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql-performance-schema-3892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n","protected":false},"excerpt":{"rendered":"<p>MySQL Performance Schema til bedre overv\u00e5gning, hurtigere analyser og m\u00e5lrettet optimering i MySQL.<\/p>","protected":false},"author":1,"featured_media":20525,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20532","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"158","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MySQL Performance","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20525","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20532","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=20532"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20532\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20525"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20532"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20532"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20532"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}