Wie man das Slow Query Log in MySQL und MariaDB aktiviert

Das Slow Query Log ist eine integrierte Diagnosefunktion von MySQL und MariaDB, die jede SQL-Anweisung aufzeichnet, deren Ausführungszeit einen konfigurierbaren Schwellenwert überschreitet. Es erfasst die Abfragedauer, Sperrzeit, untersuchte Zeilen, gesendete Zeilen und den vollständigen SQL-Text — und gibt Datenbankadministratoren und Entwicklern einen präzisen, dateibasierten Prüfpfad jeder Abfrage, die die Anwendungsleistung beeinträchtigt.

Die Aktivierung ist eine der wirkungsvollsten Maßnahmen, die Sie bei der Datenbankleistungsoptimierung ergreifen können. Im Gegensatz zu generischen Überwachungstools identifiziert das Slow Query Log genau die Anweisungen, die für Latenz verantwortlich sind, und ist damit unverzichtbar für die Indexoptimierung, Abfrageumstrukturierung und Kapazitätsplanung auf jedem Server — von einer einzelnen VPS Hosting-Umgebung bis hin zu einem mehrknotigen dedizierten Datenbankcluster.

Warum das Slow Query Log über die grundlegende Überwachung hinaus wichtig ist

Die meisten Teams greifen reaktiv auf EXPLAIN oder SHOW PROCESSLIST zurück, nachdem Benutzer Langsamkeit gemeldet haben. Das Slow Query Log arbeitet proaktiv: Es sammelt Beweise über Stunden oder Tage des realen Datenverkehrs und erfasst intermittierende Verursacher, die während eines manuellen Inspektionsfensters nie auftauchen.

Wichtige betriebliche Vorteile umfassen:

• Engpassisolierung — unterscheidet CPU-gebundene vollständige Tabellenscans von Sperrkonflikten mithilfe von Query_time vs. Lock_time-Verhältnissen
• Indexlückenanalyse — das log_queries_not_using_indexes-Flag zeigt jede Abfrage an, die einen vollständigen Scan durchführt, unabhängig von der reinen Ausführungszeit
• Regressionserkennung — der Vergleich von Log-Snapshots vor und nach einer Bereitstellung zeigt, ob neuer Code langsamere Abfragemuster eingeführt hat
• Kapazitätsplanungsnachweis — Rows_examined-Werte, die um Größenordnungen höher sind als Rows_sent, weisen auf fehlende oder falsch verwendete Indizes hin, die sich unter Last verstärken

MySQL vs. MariaDB: Vergleich der Slow Query Log-Funktionen

Beide Engines teilen dieselbe grundlegende Slow Query Log-Infrastruktur, die von MySQL 5.1 geerbt wurde, aber MariaDB hat sie auf mehrere bedeutungsvolle Weisen erweitert.

Die Optionen log_slow_verbosity und log_slow_rate_limit in MariaDB sind besonders wertvoll in Produktionsumgebungen mit hohem Durchsatz, wo das Protokollieren jeder langsamen Abfrage selbst zu einer Leistungsbelastung werden würde.

Schritt 1: Konfigurationsdatei finden

MySQL und MariaDB lesen ihre Konfiguration aus verschiedenen Standardpfaden, abhängig von der Distribution und der Installationsmethode.

MySQL:

• /etc/my.cnf (RPM-basiert: RHEL, CentOS, AlmaLinux, Rocky Linux)
• /etc/mysql/my.cnf (Debian/Ubuntu)
• /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu mit mysql-server-Paket)

MariaDB:

• /etc/my.cnf.d/server.cnf (RPM-basiert)
• /etc/mysql/mariadb.conf.d/50-server.cnf (Debian/Ubuntu)
• /etc/mysql/mariadb.cnf (ältere Debian-Layouts)

Wenn Sie nicht sicher sind, welche Datei aktiv ist, fragen Sie den laufenden Prozess ab:

mysqld --verbose --help 2>/dev/null | grep -A1 "Default options"

Dies gibt die genaue geordnete Liste der Dateien aus, die der Daemon beim Start liest, einschließlich aller !includedir-Verzeichnisse.

Öffnen Sie die primäre Konfigurationsdatei mit Ihrem bevorzugten Editor:

sudo nano /etc/my.cnf

Schritt 2: Slow Query Log-Direktiven zu [mysqld] hinzufügen

Alle Slow Query Log-Parameter gehören in den Abschnitt [mysqld]. Wenn der Abschnitt nicht vorhanden ist, erstellen Sie ihn am Anfang der Datei.

[mysqld]
# Core slow query log settings
slow_query_log          = 1
slow_query_log_file     = /var/log/mysql/slow-query.log
long_query_time         = 1

# Log queries that skip index usage entirely
log_queries_not_using_indexes = 1

# Avoid flooding the log with index warnings on low-traffic tables
min_examined_row_limit  = 100

# Log slow administrative statements (ALTER TABLE, OPTIMIZE TABLE, etc.)
log_slow_admin_statements = 1

Parameterbeschreibung:

• slow_query_log = 1 — aktiviert die Funktion; auf 0 setzen, um sie zu deaktivieren, ohne den Block zu entfernen
• slow_query_log_file — absoluter Pfad zur Log-Datei; der MySQL/MariaDB-Prozessbenutzer (mysql) muss Schreibzugriff auf das übergeordnete Verzeichnis haben
• long_query_time = 1 — Schwellenwert in Sekunden, akzeptiert Dezimalwerte (z. B. 0.5 für 500 ms); der Standardwert von 10 Sekunden ist für Webanwendungen fast immer zu permissiv
• log_queries_not_using_indexes — protokolliert vollständige Scan-Abfragen unabhängig von long_query_time; kombinieren Sie dies mit min_examined_row_limit, um Rauschen von kleinen Tabellen zu unterdrücken
• min_examined_row_limit — eine Abfrage muss mindestens so viele Zeilen untersuchen, bevor sie für die Protokollierung unter log_queries_not_using_indexes qualifiziert; verhindert, dass triviale Einzelzeilen-Lookups das Log verschmutzen
• log_slow_admin_statements — erfasst Operationen auf Schema-Ebene, die Tabellen sperren und häufig als Latenzquellen übersehen werden

MariaDB-spezifische Ergänzungen, die in der Produktion aktiviert werden sollten:

# MariaDB only — extended per-query statistics in the log
log_slow_verbosity      = query_plan,explain

# MariaDB only — log only 1 in every N qualifying queries (rate limiting)
log_slow_rate_limit     = 10

log_slow_verbosity = query_plan,explain fügt den Ausführungsplan des Optimierers direkt in jeden Log-Eintrag ein und eliminiert die Notwendigkeit, EXPLAIN nachträglich manuell auszuführen — eine erhebliche Zeitersparnis bei der Diagnose von Abfragen, die nur unter Produktionslastmustern auftreten.

Schritt 3: Log-Datei erstellen und Berechtigungen setzen

Wenn das Zielverzeichnis nicht vorhanden ist, erstellen Sie es und weisen Sie die Eigentümerschaft zu, bevor Sie den Dienst neu starten. Das Überspringen dieses Schritts ist einer der häufigsten Gründe, warum das Slow Query Log stillschweigend nicht aktiviert wird.

sudo mkdir -p /var/log/mysql
sudo touch /var/log/mysql/slow-query.log
sudo chown mysql:mysql /var/log/mysql/slow-query.log
sudo chmod 640 /var/log/mysql/slow-query.log

Auf SELinux-erzwingenden Systemen (RHEL, CentOS, AlmaLinux) muss auch der Dateikontext korrekt gesetzt werden:

sudo semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"
sudo restorecon -Rv /var/log/mysql

Das Versäumnis, den korrekten SELinux-Kontext zu setzen, führt dazu, dass der Daemon erfolgreich startet, aber stillschweigend das Schreiben in die Log-Datei überspringt — ein frustrierender Sonderfall, der keinen offensichtlichen Fehler in /var/log/messages erzeugt.

Schritt 4: Datenbankdienst neu starten

Wenden Sie die Konfigurationsänderungen an, indem Sie den Dienst neu starten. Auf systemd-basierten Distributionen (Standard auf jedem modernen Linux-Server):

# MySQL
sudo systemctl restart mysqld

# MariaDB
sudo systemctl restart mariadb

Auf älteren init.d-basierten Systemen:

# MySQL
sudo service mysqld restart

# MariaDB
sudo service mariadb restart

Überprüfen Sie nach dem Neustart, ob der Dienst sauber gestartet ist:

sudo systemctl status mysqld    # or mariadb
sudo journalctl -u mysqld -n 50 --no-pager

Jede Fehlkonfiguration in my.cnf verhindert den Start und erscheint in der Journal-Ausgabe.

Schritt 5: Slow Query Log zur Laufzeit aktivieren (ohne Neustart)

Für Produktionsserver, bei denen ein Neustart störend ist, unterstützen MySQL und MariaDB die dynamische Aktivierung des Slow Query Logs über SET GLOBAL. Auf diese Weise vorgenommene Änderungen treten sofort in Kraft, bleiben aber nach einem Dienstneustart nicht erhalten, es sei denn, sie werden auch in my.cnf geschrieben.

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow-query.log';
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 1;
SET GLOBAL min_examined_row_limit = 100;

Dies ist der richtige Ansatz für Notfalldiagnosen auf einem Live-System — aktivieren Sie es, erfassen Sie eine 15–30-minütige Stichprobe während des Spitzenverkehrs, und deaktivieren Sie es dann wieder, ohne die Konfigurationsdatei zu berühren oder den Daemon neu zu starten.

Schritt 6: Konfiguration überprüfen

Verbinden Sie sich mit dem MySQL- oder MariaDB-Client:

mysql -u root -p

Führen Sie dann eine Mustersuche in der Systemvariablentabelle durch:

SHOW VARIABLES LIKE '%slow_query%';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_queries_not_using_indexes';

Erwartete Ausgabe für eine korrekt konfigurierte Instanz:

+-------------------------------+-------------------------------+
| Variable_name                 | Value                         |
+-------------------------------+-------------------------------+
| slow_query_log                | ON                            |
| slow_query_log_file           | /var/log/mysql/slow-query.log |
+-------------------------------+-------------------------------+

+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 1.000 |
+-----------------+-------+

+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | ON    |
+-------------------------------+-------+

Sie können auch bestätigen, dass in das Log geschrieben wird, indem Sie den Slow Query-Zähler überprüfen:

SHOW GLOBAL STATUS LIKE 'Slow_queries';

Dieser Zähler erhöht sich jedes Mal, wenn eine Abfrage long_query_time überschreitet, unabhängig davon, ob die Dateiprotokollierung aktiv ist — nützlich, um zu bestätigen, dass tatsächlich langsame Abfragen auftreten, bevor Sie Zeit damit verbringen, eine leere Log-Datei zu analysieren.

Schritt 7: Das Raw Log lesen und interpretieren

Verwenden Sie tail, um das Log in Echtzeit während eines Lasttests oder Spitzenverkehrsfensters zu überwachen:

sudo tail -f /var/log/mysql/slow-query.log

Ein typischer Log-Eintrag sieht so aus:

# Time: 2024-10-11T12:45:23.489187Z
# User@Host: app_user[app_user] @ 10.0.1.45 []  Id: 1042
# Query_time: 4.561529  Lock_time: 0.000115  Rows_sent: 1  Rows_examined: 847293
# Bytes_sent: 512
SET timestamp=1697030723;
SELECT * FROM orders WHERE customer_email = 'user@example.com' ORDER BY created_at DESC;

Was jedes Feld Ihnen mitteilt:

• Query_time — gesamte Wanduhr-Ausführungszeit in Sekunden
• Lock_time — Zeit, die auf Tabellen- oder Zeilensperren gewartet wurde; ein hohes Verhältnis von Lock_time zu Query_time weist auf Konflikte hin, nicht auf einen fehlenden Index
• Rows_sent — an den Client zurückgegebene Zeilen
• Rows_examined — Zeilen, die die Storage Engine gescannt hat, um das Ergebnis zu erzeugen; ein Verhältnis von Rows_examined / Rows_sent über 100:1 ist ein starkes Signal für einen fehlenden oder wenig selektiven Index
• Bytes_sent — in MariaDB mit erweiterter Ausführlichkeit vorhanden; nützlich zur Identifizierung von Abfragen, die unnötig große Ergebnismengen zurückgeben

Im obigen Beispiel hat die Abfrage 847.293 Zeilen untersucht, um 1 Zeile zurückzugeben. Das Hinzufügen eines Index auf customer_email würde Rows_examined auf ungefähr 1 reduzieren und die Ausführungszeit von 4,5 Sekunden auf unter eine Millisekunde senken.

Schritt 8: Das Log mit mysqldumpslow und pt-query-digest analysieren

Das Lesen der rohen Log-Datei ist im großen Maßstab unpraktisch. Zwei Tools aggregieren und ordnen langsame Abfragen nach Gesamtauswirkung.

Verwendung von mysqldumpslow (im Lieferumfang von MySQL/MariaDB enthalten)

# Top 10 queries by total execution time
sudo mysqldumpslow -s t -t 10 /var/log/mysql/slow-query.log

# Top 10 queries by average execution time
sudo mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log

# Top 10 queries by rows examined
sudo mysqldumpslow -s r -t 10 /var/log/mysql/slow-query.log

mysqldumpslow normalisiert Abfrageparameter (ersetzt Literalwerte durch N oder S), sodass strukturell identische Abfragen mit unterschiedlichen Parameterwerten zusammengefasst werden — unerlässlich zur Identifizierung häufiger Muster.

Verwendung von pt-query-digest (Percona Toolkit — Empfohlen für die Produktion)

# Install Percona Toolkit (Debian/Ubuntu)
sudo apt-get install percona-toolkit

# Install Percona Toolkit (RHEL/CentOS/AlmaLinux)
sudo yum install percona-toolkit

# Generate a full digest report
sudo pt-query-digest /var/log/mysql/slow-query.log

# Show only the top 5 queries by total time
sudo pt-query-digest --limit 5 /var/log/mysql/slow-query.log

# Output to a file for later review
sudo pt-query-digest /var/log/mysql/slow-query.log > /tmp/slow_query_report.txt

pt-query-digest erstellt einen Rangbericht, der den Fingerabdruck jeder Abfrage, die gesamte Ausführungszeit, die durchschnittliche Zeit, die Aufrufanzahl und die Perzentilverteilung zeigt. Es ist deutlich leistungsfähiger als mysqldumpslow und ist das Standardwerkzeug, das professionelle DBAs für die Slow Log-Analyse verwenden.

Schritt 9: Log-Rotation mit logrotate konfigurieren

Ohne Rotation wächst das Slow Query Log unbegrenzt. Auf einem stark ausgelasteten Server mit long_query_time auf 1 Sekunde gesetzt, kann die Datei innerhalb von Tagen mehrere Gigabyte erreichen.

Erstellen Sie eine dedizierte logrotate-Konfiguration:

sudo nano /etc/logrotate.d/mysql-slow

/var/log/mysql/slow-query.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/bin/mysqladmin flush-logs 2>/dev/null || true
    endscript
}

Wichtige Direktiven erklärt:

• rotate 14 — behält 14 Tage komprimierter Archive; passen Sie dies basierend auf Ihrem Festplattenbudget und Ihren Prüfanforderungen an
• compress / delaycompress — komprimiert rotierte Dateien mit gzip, verzögert die Komprimierung jedoch um einen Zyklus, um das Komprimieren einer Datei zu vermeiden, die der Daemon möglicherweise noch geöffnet hat
• postrotate — führt mysqladmin flush-logs nach der Rotation aus, was den Daemon signalisiert, das aktuelle Log-Datei-Handle zu schließen und ein neues zu öffnen; ohne dies schreibt MySQL/MariaDB weiterhin in die umbenannte Datei bis zum nächsten Neustart

Erzwingen Sie eine manuelle Rotation, um die Konfiguration zu testen:

sudo logrotate -f /etc/logrotate.d/mysql-slow

Schritt 10: Slow Query Log deaktivieren, wenn nicht mehr benötigt

Kontinuierliches Slow Query Logging bei einem niedrigen Schwellenwert (z. B. 0,5 Sekunden) auf einem stark frequentierten Server fügt messbaren I/O-Overhead hinzu. Deaktivieren Sie es, sobald Sie ausreichend Daten gesammelt haben:

Über Konfigurationsdatei (dauerhaft):

[mysqld]
slow_query_log = 0

Dann starten Sie den Dienst neu:

sudo systemctl restart mysqld   # or mariadb

Über Laufzeitvariable (sofort, nicht dauerhaft):

SET GLOBAL slow_query_log = 'OFF';

Die Laufzeitmethode ist während der Produktionsstunden vorzuziehen — sie tritt in Millisekunden ohne Ausfallzeit in Kraft.

Erweitert: Verwendung von performance_schema als Ergänzung

Das Slow Query Log erfasst Abfragen, die einen Zeitschwellenwert überschreiten. Die performance_schema-Tabelle events_statements_summary_by_digest erfasst aggregierte Statistiken für jedes einzelne Abfragemuster, unabhängig von der Ausführungszeit. Die gemeinsame Verwendung beider gibt ein vollständiges Bild.

SELECT
    DIGEST_TEXT,
    COUNT_STAR,
    ROUND(SUM_TIMER_WAIT / 1e12, 3)     AS total_time_sec,
    ROUND(AVG_TIMER_WAIT / 1e12, 6)     AS avg_time_sec,
    SUM_ROWS_EXAMINED,
    SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

Diese Abfrage zeigt die 10 zeitaufwändigsten Abfragemuster über die gesamte Anweisungshistorie — einschließlich schneller Abfragen, die Millionen von Malen ausgeführt werden und zusammen die CPU-Zeit dominieren, was das Slow Query Log niemals erfassen würde.

Überlegungen zur Hosting-Umgebung

Der optimale long_query_time-Schwellenwert hängt stark von der Rolle und dem Ressourcenprofil des Servers ab:

• Shared-Hosting-Umgebungen — typischerweise kein direkter Zugriff auf my.cnf; verwenden Sie SET GLOBAL, wenn der Hosting-Anbieter SUPER– oder SYSTEM_VARIABLES_ADMIN-Rechte gewährt, oder fordern Sie Slow Log-Zugriff über das Kontrollpanel an
• VPS-Umgebungen — vollständiger Root-Zugriff bedeutet vollständige Kontrolle über alle Konfigurationsparameter; eine VPS mit cPanel-Installation stellt Slow Query Log-Einstellungen über den MySQL Configuration Editor von WHM bereit, der direkt in my.cnf schreibt
• Dedizierte Server — auf einem Dedizierten Server, der eine stark frequentierte Datenbank betreibt, sollten Sie long_query_time so niedrig wie 0.1 Sekunden setzen und log_slow_rate_limit (MariaDB) oder Sampling auf Anwendungsebene verwenden, um das Log-Volumen zu kontrollieren
• GPU-beschleunigte Analyse-Workloads — auf GPU Hosting-Knoten, die analytische Abfragen gegen große Datensätze ausführen, kann ein Schwellenwert von 5–10 Sekunden angemessen sein, da lang laufende analytische Abfragen erwartetes Verhalten und kein Defekt sind

Wenn Ihr Anwendungsstack ein Web-Frontend enthält, das über ein VPS Control Panel verwaltet wird, ist die Korrelation von Slow Query Log-Zeitstempeln mit den HTTP-Zugriffslog-Zeitstempeln Ihrer Anwendung eine effektive Methode, um Datenbanklatenz auf spezifische benutzerseitige Anfragen zurückzuverfolgen.

Praktische Entscheidungsmatrix: Den richtigen Schwellenwert wählen

Technische Checkliste und wichtige Erkenntnisse

Bevor Sie eine Slow Query-Untersuchung abschließen, überprüfen Sie jeden der folgenden Punkte:

• Der Abschnitt [mysqld] in my.cnf enthält slow_query_log = 1, einen gültigen slow_query_log_file-Pfad und einen long_query_time, der für Ihr Datenverkehrsprofil geeignet ist
• Die Log-Datei und ihr übergeordnetes Verzeichnis gehören dem Systembenutzer mysql mit Schreibberechtigungen; auf SELinux-Systemen ist der Dateikontext auf mysqld_log_t gesetzt
• SHOW VARIABLES LIKE '%slow_query%' bestätigt slow_query_log = ON und den korrekten Dateipfad nach dem Dienstneustart
• SHOW GLOBAL STATUS LIKE 'Slow_queries' zeigt einen nicht-null und sich erhöhenden Zähler, der bestätigt, dass tatsächlich qualifizierende Abfragen auftreten
• log_queries_not_using_indexes ist aktiviert und mit min_examined_row_limit kombiniert, um zu verhindern, dass triviale Einzelzeilen-Lookups das Log überfluten
• log_slow_admin_statements ist aktiviert, um ALTER TABLE, OPTIMIZE TABLE und ähnliche DDL-Operationen zu erfassen, die häufige Quellen unerwarteter Tabellensperren sind
• Eine logrotate-Konfiguration ist vorhanden mit einem postrotate-Hook, der mysqladmin flush-logs aufruft
• Sie haben pt-query-digest oder mysqldumpslow ausgeführt, um das Log zu aggregieren, und die Top 3–5 Abfragen nach gesamter Ausführungszeit identifiziert
• Jede identifizierte Abfrage wurde mit EXPLAIN (oder EXPLAIN ANALYZE in MySQL 8.0+) analysiert und entsprechende Indizes hinzugefügt oder die Abfragelogik umstrukturiert
• Das Slow Query Log wurde deaktiviert oder long_query_time nach Abschluss des Optimierungszyklus erhöht, um den laufenden I/O-Overhead zu minimieren

FAQ

Beeinträchtigt die Aktivierung des Slow Query Logs die Datenbankleistung?

Bei einem Schwellenwert von 1 Sekunde oder höher bei einer typischen Produktionslast ist der Overhead vernachlässigbar — in der Regel unter 1% der gesamten Abfrageausführungszeit. Der Overhead wird nur dann messbar, wenn long_query_time unter 0,1 Sekunden gesetzt wird oder wenn log_queries_not_using_indexes auf einem Schema mit vielen kleinen, nicht indizierten Tabellen aktiviert ist. Verwenden Sie log_slow_rate_limit (MariaDB) oder erhöhen Sie min_examined_row_limit, um dies zu mildern.

Kann ich das Slow Query Log aktivieren, ohne MySQL oder MariaDB neu zu starten?

Ja. Verwenden Sie SET GLOBAL slow_query_log = 'ON' und SET GLOBAL long_query_time = 1 aus einer beliebigen MySQL-Client-Sitzung mit SUPER– oder SYSTEM_VARIABLES_ADMIN-Berechtigung. Die Änderung tritt sofort in Kraft. Schreiben Sie dieselben Werte in my.cnf, um sie über Neustarts hinweg dauerhaft zu machen.

Was ist der Unterschied zwischen Query_time und Lock_time im Slow Query Log?

Query_time ist die gesamte verstrichene Wanduhrzeit von dem Moment, in dem der Server die Abfrage empfangen hat, bis zu dem Moment, in dem er die letzte Zeile an den Client gesendet hat. Lock_time ist der Teil dieser Gesamtzeit, der damit verbracht wurde, auf Tabellen- oder Zeilensperren zu warten. Eine Abfrage mit Lock_time nahe an Query_time ist ein Sperrkonfliktproblem, kein Indexproblem — die Lösung beinhaltet Transaktionsdesign oder die Reduzierung des Sperrumfangs, nicht das Hinzufügen von Indizes.

Warum ist meine Slow Query Log-Datei leer, obwohl slow_query_log = ON?

Die häufigsten Ursachen sind: (1) keine Abfragen haben long_query_time tatsächlich überschritten — überprüfen Sie mit SHOW GLOBAL STATUS LIKE 'Slow_queries'; (2) der Log-Dateipfad existiert nicht oder dem Benutzer mysql fehlt die Schreibberechtigung; (3) auf SELinux-Systemen ist der Dateikontext falsch; (4) die Variable slow_query_log_file zeigt auf einen anderen Pfad als die Datei, die Sie überprüfen — bestätigen Sie mit SHOW VARIABLES LIKE 'slow_query_log_file'.

Wie finde ich die einzelne schädlichste Abfrage im Slow Query Log?

Führen Sie pt-query-digest aus und sortieren Sie nach R/Call (untersuchte Zeilen pro Aufruf) oder Response time (gesamte kumulative Zeit). Die Abfrage an der Spitze des Response time-Rankings verbraucht die meiste aggregierte Datenbankzeit und sollte das erste Ziel für EXPLAIN-Analyse und Indexoptimierung sein. Wenn pt-query-digest nicht verfügbar ist, verwenden Sie mysqldumpslow -s t -t 1, um die einzelne Abfrage mit der höchsten Gesamtzeit zu extrahieren.