MySQL FLUSH-Befehle: Vollständige Referenz für Datenbankadministratoren

MySQL's `FLUSH`-Anweisung zwingt den Server, interne Caches neu zu laden, Log-Dateien zu schließen und wieder zu öffnen, Statuszähler zurückzusetzen und den In-Memory-Zustand mit den On-Disk-Strukturen zu synchronisieren – alles ohne einen Server-Neustart. Dies macht es zu einer der betrieblich kritischsten Befehlsfamilien, die einem Datenbankadministrator zur Verfügung stehen.

Das Verständnis jeder Variante, ihres genauen Umfangs und ihrer Nebeneffekte ist kein optionales Wissen für Produktionsumgebungen. Der Missbrauch von `FLUSH TABLES WITH READ LOCK` auf einem stark ausgelasteten OLTP-System kann beispielsweise anwendungsweite Schreibstopps von mehreren Minuten verursachen. Diese Referenz behandelt alle wesentlichen `FLUSH`-Varianten, einschließlich Verhaltensunterschiede zwischen MySQL 5.7 und 8.x, InnoDB-spezifische Auswirkungen, Replikationsrisiken und Berechtigungsanforderungen.

Warum FLUSH-Befehle in der Produktion wichtig sind

Der MySQL-Server pflegt zahlreiche In-Memory-Strukturen, um Operationen zu beschleunigen: den Host-Verbindungscache, Grant-Table-Caches, offene Tabellen-Deskriptoren, Query-Result-Caches und Storage-Engine-Buffer-Pools. Diese Caches sind während der Laufzeit maßgeblich. Wenn ein Administrator Out-of-Band-Änderungen vornimmt – Grant-Tables direkt mit `INSERT`/`UPDATE` bearbeitet, Log-Dateien auf OS-Ebene rotiert oder `.ibd`-Dateien verschiebt – wird die In-Memory-Ansicht des Servers veraltet. `FLUSH`-Befehle gleichen diese Abweichung aus.

Wichtige operative Bereiche, in denen `FLUSH` unverzichtbar ist:

• Berechtigungsweitergabe ohne Neustart von `mysqld`
• Konsistente Online-Backups mit sperr-basierten Snapshots
• Log-Rotation integriert mit `logrotate` oder benutzerdefinierten Skripten
• Performance-Baseline-Resets vor Benchmarks
• Host-Cache-Invalidierung nach Änderungen der Netzwerktopologie
• Durchsetzung der Storage-Engine-Dauerhaftigkeit vor Wartungsfenstern

Erforderliche Berechtigungen

Die meisten `FLUSH`-Varianten erfordern die `RELOAD`-Berechtigung. `FLUSH TABLES WITH READ LOCK` erfordert zusätzlich `LOCK TABLES`. In MySQL 8.0+ wurden fein abgestufte dynamische Berechtigungen (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`) eingeführt, die eine granularere Zugriffskontrolle ermöglichen, ohne die weitreichende `RELOAD`-Berechtigung zu vergeben. Wenden Sie beim Zuweisen dieser Berechtigungen an Anwendungs- oder Monitoring-Konten stets das Prinzip der minimalen Rechtevergabe an.

Vollständige Referenz: MySQL FLUSH-Befehle

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Dieser Befehl lädt die In-Memory-Grant-Tables aus der `mysql`-Systemdatenbank (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`) neu. Der Server liest diese Tabellen beim Start und speichert sie im Cache. Jedes direkte DML (`INSERT`, `UPDATE`, `DELETE`) gegen diese Tabellen umgeht den normalen `GRANT`/`REVOKE`-Mechanismus und lässt den Cache veraltet, bis `FLUSH PRIVILEGES` ausgeführt wird.

Wann zu verwenden:

• Nach dem manuellen Bearbeiten von Grant-Tables mit rohem SQL anstelle von `GRANT`/`REVOKE`-Anweisungen
• Nach dem Importieren eines mysqldump, der direkte Einfügungen in `mysql.user` enthält
• Nach der Wiederherstellung eines Teilbackups des `mysql`-Schemas

Wichtige Nuance: Wenn Sie die `GRANT`-, `REVOKE`-, `CREATE USER`- oder `DROP USER`-Anweisungen verwenden, lädt MySQL die Grant-Tables automatisch neu. `FLUSH PRIVILEGES` ist nur notwendig, wenn Sie diese Anweisungen vollständig umgehen. Das unnötige Ausführen ist harmlos, fügt jedoch eine kurze Sperre auf den Grant-Table-Cache hinzu.

Replikationshinweis: `FLUSH PRIVILEGES` wird standardmäßig in das Binary Log geschrieben und an Replikas repliziert. Dies ist im Allgemeinen das gewünschte Verhalten bei der Benutzerverwaltung in einer Replikationstopologie.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Dieser Befehl schließt alle aktuell geöffneten Tabellen-Dateideskriptoren und entfernt sie aus dem Table Definition Cache (TDC). Beim nächsten Zugriff öffnet MySQL die Tabellendateien erneut von der Festplatte. Dies ist nach jeder Out-of-Band-Dateimanipulation unerlässlich.

Wann zu verwenden:

• Nach dem Kopieren oder Ersetzen von `.frm`-, `.ibd`- oder `.MYD`/`.MYI`-Dateien auf OS-Ebene
• Um Table-Cache-Speicher auf Servern mit einem sehr großen `table_open_cache`-Wert freizugeben
• Als Voraussetzung vor der Verwendung von `IMPORT TABLESPACE` bei InnoDB-Transportable-Tablespace-Operationen

Performance-Überlegung: Auf einem Server mit Tausenden offener Tabellen erwirbt `FLUSH TABLES` kurzzeitig eine globale Sperre. Auf Systemen mit hoher Parallelität kann dies zu einer merklichen Latenzspitze führen. Bevorzugen Sie die tabellenspezifische Form (`FLUSH TABLES tbl1, tbl2`), um die Auswirkungen zu minimieren.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Dies ist eine der mächtigsten und potenziell störendsten `FLUSH`-Varianten. Sie schließt alle offenen Tabellen, leert den Query-Cache und erwirbt eine globale Lesesperre, die alle Schreiboperationen über alle Datenbanken hinweg verhindert. Die Sperre bleibt bestehen, bis `UNLOCK TABLES` ausgegeben wird oder die Sitzung endet.

Wann zu verwenden:

• Vor der Erstellung eines physischen Backups mit Tools wie `mysqldump –single-transaction` (für reine InnoDB-Datenbanken ist dies nicht notwendig – siehe unten)
• Vor der Verwendung von `mysqlpump` oder `xtrabackup` in Nicht-InnoDB-Umgebungen
• Um einen zeitpunktgenauen konsistenten Snapshot über gemischte Storage-Engines (InnoDB + MyISAM) zu erstellen

Kritische Falle – reine InnoDB-Datenbanken: Für Datenbanken, die ausschließlich InnoDB-Tabellen verwenden, ist `FTWRL` fast nie notwendig. `mysqldump –single-transaction` öffnet eine Repeatable-Read-Transaktion, die einen konsistenten Snapshot bereitstellt, ohne Schreibvorgänge zu blockieren. Die Verwendung von `FTWRL` in diesem Szenario verursacht unnötige Schreibstopps.

Replikationsrisiko: Wenn `FTWRL` auf einer Replik ausgeführt wird, blockiert es den SQL-Applier-Thread, was dazu führt, dass sich der Replikationsrückstand für die Dauer der Sperre ansammelt. Überwachen Sie immer `Seconds_Behind_Master` nach dem Aufheben der Sperre.

Metadata-Lock-Interaktion: In MySQL 5.7+ wartet `FTWRL` darauf, dass alle aktiven Transaktionen abgeschlossen werden, bevor die globale Sperre erworben wird. Auf einem stark ausgelasteten Server mit lang laufenden Transaktionen kann dieses Warten unbegrenzt sein. Verwenden Sie `SHOW PROCESSLIST`, um blockierende Transaktionen zu identifizieren, bevor Sie `FTWRL` ausführen.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL pflegt einen Host-Cache, der den Verbindungsversuchsverlauf aufzeichnet, einschließlich der Anzahl fehlgeschlagener Authentifizierungen. Wenn ein Host mehr als `max_connect_errors` aufeinanderfolgende fehlgeschlagene Verbindungen ansammelt, blockiert MySQL alle nachfolgenden Verbindungen von diesem Host, bis der Cache-Eintrag gelöscht wird.

Wann zu verwenden:

• Wenn ein legitimer Client-Host aufgrund des Überschreitens von `max_connect_errors` blockiert ist
• Nach der Behebung eines Netzwerkproblems, das wiederholte TCP-Verbindungsfehler verursacht hat
• Nach dem Ändern von DNS-Einträgen, die beeinflussen, wie der Server Client-Hostnamen auflöst

MySQL 8.0-Alternative: In MySQL 8.0+ können Sie die Host-Cache-Tabelle auch direkt abschneiden:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Dies erzielt dasselbe Ergebnis und ist in automatisierten Skripten transparenter.

Proaktive Konfiguration: Anstatt sich reaktiv auf `FLUSH HOSTS` zu verlassen, setzen Sie `max_connect_errors` auf einen höheren Wert (z. B. `10000`) oder setzen Sie `host_cache_size = 0`, um den Host-Cache in vertrauenswürdigen internen Netzwerken vollständig zu deaktivieren.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Setzt die meisten Sitzungs- und globalen Statusvariablen auf null zurück. Dies umfasst Zähler wie `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` und Hunderte andere, die über `SHOW STATUS` oder `performance_schema` zugänglich sind.

Wann zu verwenden:

• Unmittelbar vor einem kontrollierten Benchmark, um eine saubere Messbasis zu etablieren
• Nach einer Konfigurationsänderung (z. B. Anpassen von `innodb_buffer_pool_size`), um den Effekt auf I/O-Metriken zu isolieren
• Beim Skripten von Performance-Regressionstests, die Vorher/Nachher-Zählerdeltas vergleichen

Wichtige Einschränkung: `FLUSH STATUS` setzt nicht alle Zähler zurück. Variablen wie `Uptime`, `Uptime_since_flush_status` und bestimmte interne InnoDB-Metriken sind nicht betroffen. Für umfassendes Monitoring verwenden Sie direkt `performance_schema`-Tabellen, die eine Thread- und Ereignisgranularität bieten, die `FLUSH STATUS` nicht bereitstellen kann.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` schließt alle Server-Log-Dateien und öffnet sie erneut. MySQL 5.7.2+ führte die Möglichkeit ein, bestimmte Log-Typen einzeln zu leeren, was in der Produktion weit vorzuziehen ist.

Wann zu verwenden:

• Als Teil eines `logrotate`-Post-Rotate-Skripts, um MySQL zu signalisieren, nach der Rotation der alten Datei eine neue Log-Datei zu öffnen
• Um eine neue Binary-Log-Datei zu erzwingen (äquivalent zu `FLUSH BINARY LOGS`), was die Binary-Log-Sequenznummer erhöht
• Vor dem Archivieren alter Logs, um sicherzustellen, dass alle ausstehenden Schreibvorgänge auf die Festplatte geleert werden

Binary-Log-Besonderheiten: `FLUSH BINARY LOGS` erstellt eine neue Binary-Log-Datei und schreibt ein `Rotate_event` in die alte Datei. Dies ist der korrekte Weg, Binary Logs für die Point-in-Time-Recovery (PITR)-Archivierung zu segmentieren. Die aktuelle Binary-Log-Datei und Position können mit `SHOW MASTER STATUS` (MySQL 5.7) oder `SHOW BINARY LOG STATUS` (MySQL 8.4+) bestätigt werden.

logrotate-Integrationsbeispiel:

“`bash

/etc/logrotate.d/mysql

/var/log/mysql/mysql-slow.log {

daily

rotate 7

missingok

compress

postrotate

mysqladmin -u root -p flush-logs

endscript

}

“`

7. FLUSH QUERY CACHE

“`sql

FLUSH QUERY CACHE;

RESET QUERY CACHE;

“`

Veraltungswarnung: Der MySQL Query Cache wurde in MySQL 5.7.20 als veraltet markiert und in MySQL 8.0 vollständig entfernt. Wenn Sie MySQL 8.0 oder höher verwenden, existiert dieser Befehl nicht.

Für MySQL 5.6/5.7-Umgebungen, in denen der Query Cache noch aktiv ist:

• `FLUSH QUERY CACHE` defragmentiert den Query-Cache-Speicher, ohne gecachte Ergebnisse zu entfernen
• `RESET QUERY CACHE` entfernt alle gecachten Query-Ergebnisse vollständig

Wann zu verwenden (nur MySQL 5.6/5.7):

• Nach einer großen Batch-Datenänderung, die einen erheblichen Teil der gecachten Ergebnisse ungültig macht
• Wenn `Qcache_free_blocks` im Verhältnis zu `Qcache_total_blocks` hoch ist, was auf Fragmentierung hinweist
• Vor dem Deaktivieren des Query Caches (`SET GLOBAL query_cache_size = 0`), um Speicher sauber freizugeben

Moderne Alternative: Verwenden Sie in MySQL 8.0+ InnoDB Buffer Pool Warming (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) und `performance_schema` für Query-Level-Analysen stattdessen.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Setzt die von MySQL's eingebautem Rate-Limiting verfolgten Ressourcenzähler pro Benutzer zurück. Diese Zähler erzwingen Limits, die in `CREATE USER`- oder `GRANT`-Anweisungen definiert sind:

• `MAX_QUERIES_PER_HOUR`
• `MAX_UPDATES_PER_HOUR`
• `MAX_CONNECTIONS_PER_HOUR`
• `MAX_USER_CONNECTIONS`

Wann zu verwenden:

• Wenn ein Benutzer sein stündliches Query-Kontingent ausgeschöpft hat und sofortiger Zugriff wiederhergestellt werden muss, bevor der Zähler an der nächsten Stundengrenze natürlich zurückgesetzt wird
• Nach der Erhöhung der Ressourcenlimits eines Benutzers und dem Wunsch, dass die neuen Limits sofort wirksam werden
• Während der Entwicklung/des Testens, um Kontingente zwischen Testläufen zurückzusetzen

Hinweis: Dieser Befehl setzt Zähler für alle Benutzer gleichzeitig zurück. Es gibt keine Benutzergranularität auf der `FLUSH`-Ebene. Wenn Sie die Zähler eines einzelnen Benutzers zurücksetzen müssen, besteht die einzige Möglichkeit darin, ihr Konto mit `ALTER USER` zu ändern und dann `FLUSH USER_RESOURCES` auszugeben.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Zwingt alle Storage-Engines, ihre ausstehenden Schreibpuffer in ihre jeweiligen Log-Dateien zu leeren. Für InnoDB bedeutet dies das Leeren des Redo-Log-Puffers (`innodb_log_buffer_size`) in die InnoDB-Redo-Log-Dateien auf der Festplatte.

Wann zu verwenden:

• Vor der Erstellung eines Cold Backups von InnoDB-Datendateien, um die Redo-Log-Konsistenz sicherzustellen
• Bei der Fehlerbehebung der Storage-Engine, um pufferbezogene Dateninkonsistenzen auszuschließen
• Als Teil einer Vor-Wartungs-Checkliste vor dem Stoppen des MySQL-Dienstes

InnoDB-Dauerhaftigkeitskontext: Die `innodb_flush_log_at_trx_commit`-Einstellung von InnoDB steuert, wie aggressiv das Redo-Log bei jedem Transaktions-Commit geleert wird. `FLUSH ENGINE LOGS` ist eine manuelle Überschreibung, die unabhängig von dieser Einstellung ein Leeren erzwingt. Dies ist in Szenarien nützlich, in denen Sie einen garantierten Dauerhaftigkeits-Checkpoint benötigen, ohne eine Transaktion zu committen.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Lädt die durch die `–des-key-file`-Server-Startoption angegebene DES-Verschlüsselungsschlüsseldatei neu. Diese Schlüsseldatei wurde von den `DES_ENCRYPT()`- und `DES_DECRYPT()`-Funktionen verwendet.

Veraltungswarnung: Die `DES_ENCRYPT()`- und `DES_DECRYPT()`-Funktionen wurden in MySQL 5.7.6 als veraltet markiert und in MySQL 8.0 entfernt. Dieser Befehl ist daher nur auf älteren MySQL 5.6/5.7-Installationen relevant.

Moderne Verschlüsselungsalternative: Verwenden Sie MySQL's native Data-at-Rest-Verschlüsselung (InnoDB-Tablespace-Verschlüsselung über `ALTER TABLE … ENCRYPTION='Y'`) in Kombination mit MySQL Keyring-Plugins (`keyring_file`, `keyring_okv`, `keyring_aws`) für Produktionsverschlüsselungsanforderungen.

FLUSH-Befehlsvergleichstabelle

Replikation und FLUSH: Was repliziert wird

Nicht alle `FLUSH`-Befehle werden an Replik-Server repliziert. Das Verständnis dieser Unterscheidung ist in HA- und Replikationstopologien entscheidend:

Standardmäßig repliziert:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (wird als `Rotate_event` in das Binary Log geschrieben)
• `FLUSH USER_RESOURCES`

Nicht repliziert (sitzungslokal oder explizit ausgeschlossen):

• `FLUSH TABLES WITH READ LOCK` — wird nie in das Binary Log geschrieben
• `FLUSH STATUS` — betrifft nur die lokalen Zähler des Servers
• `FLUSH HOSTS` — nur lokaler Host-Cache
• `FLUSH ENGINE LOGS` — nur lokaler Engine-Zustand

Um zu verhindern, dass ein bestimmter `FLUSH`-Befehl repliziert wird, auch wenn er es normalerweise würde, verwenden Sie den `LOCAL`- oder `NO_WRITE_TO_BINLOG`-Modifikator:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Dies ist nützlich, wenn Berechtigungen unabhängig auf einer Replik verwaltet werden (z. B. das Hinzufügen von Monitoring-Benutzern, die auf dem Primary nicht existieren sollen).

Automatisierung von FLUSH-Operationen mit mysqladmin

Viele `FLUSH`-Operationen können von der Shell aus ausgelöst werden, ohne eine MySQL-Client-Sitzung zu öffnen, was in Cron-Jobs und Wartungsskripten nützlich ist:

“`bash

Flush binary logs

mysqladmin -u root -p flush-logs

Flush privileges

mysqladmin -u root -p flush-privileges

Flush host cache

mysqladmin -u root -p flush-hosts

Flush status counters

mysqladmin -u root -p flush-status

“`

Für Produktionsumgebungen speichern Sie Anmeldeinformationen in `~/.my.cnf` mit `chmod 600` anstatt `-p` interaktiv zu übergeben, oder verwenden Sie MySQL's `–login-path`-Mechanismus mit `mysql_config_editor`.

Überlegungen zur Hosting-Umgebung

Die Möglichkeit, `FLUSH`-Befehle auszuführen, hängt stark von der Hosting-Umgebung und dem gewährten Datenbankzugriffsniveau ab. Bei einem VPS Hosting-Plan haben Sie in der Regel vollen Root-Zugriff auf die MySQL-Instanz, was bedeutet, dass Sie jede `FLUSH`-Variante ausführen, `my.cnf` ändern und die Log-Rotation direkt verwalten können. Dies ist die empfohlene Mindestumgebung für jede ernsthafte Datenbankadministrationsarbeit.

Bei Shared Web Hosting ist der Datenbankzugriff in der Regel auf einen nicht privilegierten Benutzer ohne die `RELOAD`-Berechtigung beschränkt, was die meisten `FLUSH`-Befehle unzugänglich macht. Wenn Ihre Anwendung Berechtigungsverwaltung, Log-Rotationssteuerung oder backup-konsistente Snapshots erfordert, wird eine Shared-Umgebung ein hartes Hindernis sein.

Für hochdurchsatzfähige Datenbank-Workloads – insbesondere solche mit häufigen `FLUSH ENGINE LOGS`-Operationen oder großen InnoDB-Buffer-Pools – bieten Dedizierte Server den I/O-Durchsatz und die Speicherbandbreite, die erforderlich sind, um diese Operationen nicht störend zu gestalten. Ein `FLUSH TABLES WITH READ LOCK` auf einem Server mit 256 GB Buffer-Pool-Daten dauert messbar länger als auf einem Server mit schnellem NVMe-Speicher und dedizierten I/O-Kanälen.

Wenn Sie eine MySQL-Instanz zusammen mit einem Web-Control-Panel verwalten, bietet VPS mit cPanel eine verwaltete Umgebung, in der einige `FLUSH`-Operationen (insbesondere Log-Rotation und Berechtigungs-Reloads) automatisch von der Datenbankverwaltungsschicht des Control Panels gehandhabt werden, was den Bedarf an manuellen Eingriffen reduziert.

Für datenbankgestützte Anwendungen, die ein vollständiges Control-Panel-Ökosystem erfordern, hilft die Überprüfung der verfügbaren VPS Control Panels dabei, zu identifizieren, welches Panel am besten in Ihren MySQL-Administrations-Workflow integriert ist.

Wichtige Checkliste

Verwenden Sie diese Entscheidungsmatrix, bevor Sie einen `FLUSH`-Befehl in der Produktion ausführen:

• Vor `FLUSH TABLES WITH READ LOCK`: Bestätigen Sie, dass keine lang laufenden Transaktionen aktiv sind (`SHOW PROCESSLIST`). Überprüfen Sie, ob Ihre Datenbank nur InnoDB verwendet – wenn ja, verwenden Sie stattdessen `–single-transaction`.
• Vor `FLUSH PRIVILEGES`: Bestätigen Sie, dass Sie rohes DML auf Grant-Tables verwenden. Wenn Sie `GRANT`/`REVOKE` verwendet haben, ist dieser Befehl redundant.
• Vor `FLUSH LOGS`: Stellen Sie sicher, dass Ihr Log-Rotationsskript die alte Log-Datei bereits verschoben/umbenannt hat, bevor MySQL signalisiert wird, sie erneut zu öffnen.
• Vor `FLUSH HOSTS`: Identifizieren Sie zuerst die Ursache der Verbindungsfehler. Das Leeren des Host-Caches ohne Behebung des zugrunde liegenden Problems führt dazu, dass der Host erneut blockiert wird.
• In MySQL 8.0+: Entfernen Sie alle `FLUSH QUERY CACHE`- oder `FLUSH DES_KEY_FILE`-Aufrufe aus Skripten – diese Befehle existieren nicht und verursachen Fehler.
• In Replikationstopologien: Verwenden Sie `FLUSH LOCAL` oder `FLUSH NO_WRITE_TO_BINLOG`, wenn die Operation nicht an Replikas weitergegeben werden soll.
• Für die Automatisierung: Verwenden Sie `mysqladmin flush-*`-Befehle in Skripten anstatt vollständige MySQL-Client-Sitzungen zu öffnen.
• Berechtigungs-Auditing: Bevorzugen Sie dynamische MySQL 8.0-Berechtigungen (`FLUSH_STATUS`, `FLUSH_TABLES` usw.) gegenüber der weitreichenden `RELOAD`-Berechtigung für Monitoring- und Backup-Konten.

Häufig gestellte Fragen

Muss FLUSH PRIVILEGES nach jeder GRANT- oder REVOKE-Anweisung ausgeführt werden?

Nein. `GRANT`, `REVOKE`, `CREATE USER` und `DROP USER` laden die Grant-Tables automatisch im Speicher neu. `FLUSH PRIVILEGES` ist nur nach direkten DML-Änderungen an den `mysql`-Systemtabellen notwendig (z. B. `UPDATE mysql.user SET …`).

Kann FLUSH TABLES WITH READ LOCK zu Anwendungsausfällen führen?

Ja. Es erwirbt eine globale Schreibsperre, die alle `INSERT`-, `UPDATE`-, `DELETE`- und DDL-Operationen über jede Datenbank auf dem Server blockiert. Auf einem stark ausgelasteten OLTP-System können selbst wenige Sekunden `FTWRL` Connection-Pools erschöpfen und kaskadierende Anwendungsfehler verursachen. Für reine InnoDB-Datenbanken verwenden Sie `mysqldump –single-transaction`, um dies vollständig zu vermeiden.

Ist FLUSH STATUS dasselbe wie ein Neustart des MySQL-Servers für Benchmark-Zwecke?

Nein. `FLUSH STATUS` setzt die meisten Statuszähler zurück, löscht jedoch nicht den InnoDB-Buffer-Pool, setzt keine Verbindungszustände zurück und beeinflusst nicht die akkumulierten `performance_schema`-Statistiken. Für einen echten Clean-Slate-Benchmark ist ein Server-Neustart kombiniert mit dem Leeren des Buffer Pools genauer, obwohl dies in der Produktion unpraktisch ist.

Warum existiert FLUSH HOSTS in einigen MySQL 8.0-Dokumentationen nicht als eigenständiger Befehl?

`FLUSH HOSTS` funktioniert in MySQL 8.0 weiterhin, aber die bevorzugte Methode ist `TRUNCATE TABLE performance_schema.host_cache`, was expliziter ist und ohne die `RELOAD`-Berechtigung ausgeführt werden kann, wenn der Benutzer `DELETE` auf `performance_schema` hat. Beide erzielen dasselbe Ergebnis.

Was passiert, wenn FLUSH ENGINE LOGS während der Spitzenschreiblast auf InnoDB ausgeführt wird?

Es erzwingt ein synchrones Leeren des InnoDB-Log-Puffers auf die Festplatte, was einen kurzen Schreibstopp verursachen kann, wenn sich die Redo-Log-Dateien auf langsamem Speicher befinden. Auf NVMe-gestützten Servern ist die Auswirkung typischerweise unter einer Millisekunde. Auf rotierenden Festplatten oder stark ausgelastetem SAN-Speicher kann es zu merklichen Latenzspitzen führen. Planen Sie diese Operation nach Möglichkeit in Zeitfenstern mit geringem Datenverkehr.