Dateien hier ablegen

SQL-Upload ( 0 ) x -

Drücken Sie Strg+Enter, um die Abfrage auszuführen Drücken Sie Enter, um die Abfrage auszuführen
aufsteigend
absteigend
Reihenfolge:
SQL Debugger
Zähler
Ausführungsreihenfolge
Nötige Zeit
Sortieren nach:
Abfragen umgruppieren
Abfragen voneinander lösen
Zuklappen Aufklappen Nachverfolgung anzeigen Nachverfolgung ausblenden Anzahl: Nötige Zeit:
Lesezeichen
Aktualisieren
Hinzufügen
Keine Lesezeichen
Lesezeichen hinzufügen
Optionen
Standardwerte wiederherstellen
Zuklappen Aufklappen Erneut abfragen Bearbeiten Erklären Messen Lesezeichen Abfrage fehlgeschlagen Datenbank: Abfragezeit:

Ratgebersystem

Mögliche Performance-Probleme

Problem:
Die Betriebszeit beträgt weniger als ein Tag, Leistung-Optimierungen könnten ungenau sein.
Empfehlung:
Um genauere Durchschnittswerte zu haben, wird empfohlen, den Server mehr als einen Tag laufen zu lassen, bevor dieser Analysierer ausgeführt wird
Ausrichtung:
Die Betriebszeit beträgt nur 0 Tage, 0 Stunden, 40 Minuten und 39 Sekunden
Benutzte Variable/Formel:
Uptime
Test:
value < 86400
Problem:
long_query_time ist auf 10 Sekunden oder mehr gesetzt, somit werden nur langsame Abfragen geloggt, die länger als 10 Sekunden laufen.
Empfehlung:
Es wird empfohlen, long_query_time auf einen niedrigeren Wert zu setzen, abhängig von Ihrer Umgebung. Gewöhnlich wird ein Wert von 1 bis 5 Sekunden vorgeschlagen.
Ausrichtung:
long_query_time ist auf 10 Sekunde(n) eingestellt.
Benutzte Variable/Formel:
long_query_time
Test:
value >= 10
Problem:
Die Überwachung langsamer Anfragen ist deaktiviert.
Empfehlung:
Loggen von langsamen Abfragen einschalten, indem slow_query_log auf 'ON' gesetzt wird. Das hilft beim Erkennen von grauenhaft langsamen Abfragen.
Ausrichtung:
slow_query_log ist deaktiviert
Benutzte Variable/Formel:
slow_query_log
Test:
value == 'OFF'
Problem:
Es werden viele Zeilen sortiert.
Empfehlung:
Auch wenn ein hoher Anteil an Zeilensortierungen nicht falsch ist, sollten Sie darauf achten, dass die Abfragen, die viele Sortierungen verwenden, indizierte Spalten in der ORDER-BY-Klausel verwenden, da dies zu viel schnellerem Sortieren führt.
Ausrichtung:
Durchschnitt sortierte Zeilen: 17.95 pro Sekunde
Benutzte Variable/Formel:
Sort_rows / Uptime
Test:
value * 60 >= 1
Problem:
Es werden zu viele Joins ohne die Benutzung von Indizes durchgeführt.
Empfehlung:
Dies bedeutet, dass Joins vollständige Tabellenscans durchführen. Indizes für die Spalten zu verwenden, die in den Join-Bedingungen eingesetzt werden, wird die Joins erheblich beschleunigen.
Ausrichtung:
Durchschnitt Tabellen-Joins: 10.98 pro Sekunde, dieser Wert sollte kleiner als 1 pro Stunde sein
Benutzte Variable/Formel:
(Select_range_check + Select_scan + Select_full_join) / Uptime
Test:
value * 60 * 60 > 1
Problem:
Die Lese-Rate des ersten Indexeintrag ist hoch.
Empfehlung:
Dies bedeutet in der Regel häufig vollständige Indexscans. Vollständige Indexscans sind schneller als Tablenscans aber sie kosten viele CPU-Zyklen in großen Tabellen, wenn diese Tabellen große Mengen von Aktualisierungen und Löschungen haben oder hatten. Ein Ausführen von "OPTIMIZE TABLE" auf diese Tabellen kann die Menge verringern und/oder die Geschwindigkeit der vollständigen Indexscans beschleunigen. Abgesehen davon können vollständige Indexscans nur durch Umschreiben der Abfragen reduziert werden.
Ausrichtung:
Durchschnitt Indexscans: 39.04 pro Minute, dieser Wert sollte kleiner als 1 pro Stunde sein
Benutzte Variable/Formel:
Handler_read_first / Uptime
Test:
value * 60 * 60 > 1
Problem:
Die Lese-Rate fester Positionen ist hoch.
Empfehlung:
Dies deutet darauf hin, dass viele Abfragen Sortieren und/oder vollständige Tabellen-Scan benötigen, einschließlich Join-Abfragen die keine Indizes verwenden. Fügen Sie Indizes hinzu wo zutreffend.
Ausrichtung:
Durchschnittliche Lese-Rate fester Positionen: 17.76 pro Sekunde, dieser Wert sollte kleiner als 1 pro Stunde sein
Benutzte Variable/Formel:
Handler_read_rnd / Uptime
Test:
value * 60 * 60 > 1
Problem:
Lese-Rate nächste Tabellenzeile ist hoch.
Empfehlung:
Dies deutet darauf hin, dass viele Abfragen Full Table Scans durchführen. Fügen Sie Indizes hinzu wo zutreffend.
Ausrichtung:
Lese-Rate nächste Tabellenzeile: 284.15 pro Sekunde, dieser Wert sollte kleiner als 1 pro Stunde sein
Benutzte Variable/Formel:
Handler_read_rnd_next / Uptime
Test:
value * 60 * 60 > 1
Problem:
Viele temporäre Tabellen werden auf die Festplatte geschrieben, anstelle im Speicher gehalten zu werden.
Empfehlung:
Erhöhen von max_heap_table_size und tmp_table_size kann helfen. Jedoch werden einige temporären Tabellen immer unabhängig vom Wert dieser Variablen auf den Datenträger geschrieben. Um dies zu verhindern müssen Sie Ihre Abfragen so umschreiben, dass diese Bedingungen (Innerhalb einer temporären Tabelle: Vorhandensein eines BLOB- oder TEXT-Spalte oder eine Spalte größer als 512 Bytes) nicht eintreten, wie in der MySQL-Dokumentation erwähnt wird
Ausrichtung:
Rate auf Festplatte geschriebener temporärer Tabellen: 1.03 pro Sekunde, dieser Wert sollte kleiner als 1 pro Stunde sein
Benutzte Variable/Formel:
Created_tmp_disk_tables / Uptime
Test:
value * 60 * 60 > 1
Problem:
MyISAM Schlüssel-Cache (Indizes-Cache) % benutzt ist niedrig.
Empfehlung:
Sie müssen möglicherweise Ihren key_buffer_size verkleinern, überprüfen Sie Ihre Tabellen, um zu sehen ob Indizes entfernt wurden, oder überprüfen Sie Abfragen und Erwartungen, welche Indizes verwendet werden.
Ausrichtung:
maximal wurden % des MyISAM Sortierungspuffers benutzt: 0%, dieser Wert sollte über 95% liegen
Benutzte Variable/Formel:
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
Test:
value < 95
Problem:
Hohe Anzahl an Tabellen-Öffnungen.
Empfehlung:
Öffnen von Tabellen erfordert Festplatten I/O, welches langsam ist. Erhöhung von table_open_cache könnte dies vermeiden.
Ausrichtung:
Häufigkeit von Tabellenöffnungen: 3.39 pro Minute, dieser Wert sollte weniger als 10 pro Stunde sein
Benutzte Variable/Formel:
Opened_tables / Uptime
Test:
value*60*60 > 10
Problem:
Die Anzahl der Datei-Zugriffe ist hoch.
Empfehlung:
Sie sollten open_files_limit erhöhen, und überprüfen Sie das Fehlerprotokoll beim Neustart nach der Änderung von open_files_limit.
Ausrichtung:
Geöffnete Dateien Rate: 1.87 pro Minute, dieser Wert sollte kleiner als 5 pro Stunde sein
Benutzte Variable/Formel:
Open_files / Uptime
Test:
value * 60 * 60 > 5
Problem:
Zu viele Verbindungen werden abgebrochen.
Empfehlung:
Verbindungen sind in der Regel abgebrochen, wenn sie nicht autorisiert werden können. Dieser Artikel könnte Ihnen helfen der Quelle auf die Spur zu kommen.
Ausrichtung:
Die Rate der abgebrochenen Verbindungen ist 2.95 pro Stunde, dieser Wert sollte weniger als 1 pro Stunde sein
Benutzte Variable/Formel:
Aborted_connects / Uptime
Test:
value * 60 * 60 > 1
Problem:
Weniger als 80% des Abfragen-Zwischenspeichers werden benutzt.
Empfehlung:
Das könnte daher kommen, dass query_cache_limit zu niedrig ist. Auch das Leeren des Abfragecaches könnte helfen.
Ausrichtung:
Das aktuelle Verhältnis von freiem Abfrage-Zwischenspeicher zur Größe des gesamten Abfrage-Zwischenspeichers ist 9%. Es sollte über 80% betragen
Benutzte Variable/Formel:
100 - Qcache_free_memory / query_cache_size * 100
Test:
value < 80
Problem:
Die maximale Größe des Ergebnissets im Abfragecache ist 1 MiB, wie standardmäßig.
Empfehlung:
Verändern von query_cache_limit (in der Regel durch erhöhen) kann die Effizienz steigern. Diese Variable bestimmt die maximale Größe eines Abfrageergebnis, das in den Abfrage-Cache eingefügt werden soll. Wenn es viele Abfrageergebnisse über 1 MiB gibt die sich auch zwischenspeichern lassen (viele Lesevorgänge, wenig schreibt) dann kann ein erhöhen von query_cache_limit die Effizienz erhöhen. Während bei viele Abfrageergebnisse über 1 MiB die nicht sehr gut zwischenspeicherbar sind (oft aufgrund von Aktualisierungen der Tabelle ungültig) ein Erhöhen von query_cache_limit die Effizienz reduzieren kann.
Ausrichtung:
query_cache_limit ist auf 1 MiB gesetzt
Benutzte Variable/Formel:
query_cache_limit
Test:
value == 1024*1024