Commandes MySQL FLUSH : Référence complète pour les administrateurs de bases de données

L’instruction `FLUSH` de MySQL force le serveur à recharger les caches internes, fermer et rouvrir les fichiers journaux, réinitialiser les compteurs de statut et synchroniser l’état en mémoire avec les structures sur disque — le tout sans nécessiter un redémarrage du serveur. Cela en fait l’une des familles de commandes les plus critiques sur le plan opérationnel disponibles pour un administrateur de base de données.

Comprendre chaque variante, sa portée précise et ses effets secondaires n’est pas une connaissance facultative pour les environnements de production. Une mauvaise utilisation de `FLUSH TABLES WITH READ LOCK` sur un système OLTP très sollicité, par exemple, peut provoquer des blocages d’écriture à l’échelle de l’application pendant plusieurs minutes. Cette référence couvre toutes les variantes significatives de `FLUSH`, y compris les différences de comportement entre MySQL 5.7 et 8.x, les implications spécifiques à InnoDB, les risques liés à la réplication et les exigences en matière de privilèges.

Pourquoi les commandes FLUSH sont importantes en production

Le serveur MySQL maintient de nombreuses structures en mémoire pour accélérer les opérations : le cache de connexions hôtes, les caches de tables de droits, les descripteurs de tables ouvertes, les caches de résultats de requêtes et les pools de tampons des moteurs de stockage. Ces caches font autorité lors de l’exécution. Lorsqu’un administrateur effectue des modifications hors bande — en modifiant directement les tables de droits avec `INSERT`/`UPDATE`, en faisant pivoter les fichiers journaux au niveau du système d’exploitation, ou en déplaçant des fichiers `.ibd` — la vue en mémoire du serveur devient obsolète. Les commandes `FLUSH` permettent de réconcilier cette divergence.

Catégories opérationnelles clés où `FLUSH` est indispensable :

• Propagation des privilèges sans redémarrer `mysqld`
• Sauvegardes en ligne cohérentes à l’aide de snapshots basés sur des verrous
• Rotation des journaux intégrée avec `logrotate` ou des scripts personnalisés
• Réinitialisations de référence de performance avant les benchmarks
• Invalidation du cache hôte après des changements de topologie réseau
• Application de la durabilité du moteur de stockage avant les fenêtres de maintenance

Privilèges requis

La plupart des variantes de `FLUSH` nécessitent le privilège `RELOAD`. `FLUSH TABLES WITH READ LOCK` requiert en outre `LOCK TABLES`. Dans MySQL 8.0+, des privilèges dynamiques à granularité fine (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`) ont été introduits, permettant un contrôle d’accès plus granulaire sans accorder le large privilège `RELOAD`. Appliquez toujours le principe du moindre privilège lors de l’attribution de ces droits aux comptes d’application ou de surveillance.

Référence complète : commandes MySQL FLUSH

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Cette commande recharge les tables de droits en mémoire depuis la base de données système `mysql` (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`). Le serveur lit ces tables au démarrage et les met en cache. Tout DML direct (`INSERT`, `UPDATE`, `DELETE`) sur ces tables contourne le mécanisme normal `GRANT`/`REVOKE`, laissant le cache obsolète jusqu’à l’exécution de `FLUSH PRIVILEGES`.

Quand l’utiliser :

• Après avoir modifié manuellement les tables de droits avec du SQL brut plutôt qu’avec des instructions `GRANT`/`REVOKE`
• Après l’importation d’un mysqldump qui inclut des insertions directes dans `mysql.user`
• Après la restauration d’une sauvegarde partielle du schéma `mysql`

Nuance critique : Lorsque vous utilisez les instructions `GRANT`, `REVOKE`, `CREATE USER` ou `DROP USER`, MySQL recharge automatiquement les tables de droits. `FLUSH PRIVILEGES` n’est nécessaire que lorsque vous contournez entièrement ces instructions. L’exécuter inutilement est sans danger, mais ajoute un bref verrou sur le cache des tables de droits.

Note sur la réplication : `FLUSH PRIVILEGES` est écrit dans le journal binaire et répliqué vers les réplicas par défaut. C’est généralement le comportement souhaité lors de la gestion des utilisateurs dans une topologie de réplication.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Cette commande ferme tous les descripteurs de fichiers de tables actuellement ouverts et les supprime du cache de définition de tables (TDC). Lors du prochain accès, MySQL rouvre les fichiers de tables depuis le disque. Cela est essentiel après toute manipulation de fichiers hors bande.

Quand l’utiliser :

• Après avoir copié ou remplacé des fichiers `.frm`, `.ibd` ou `.MYD`/`.MYI` au niveau du système d’exploitation
• Pour libérer la mémoire du cache de tables sur des serveurs avec une valeur `table_open_cache` très élevée
• Comme prérequis avant d’utiliser `IMPORT TABLESPACE` dans les opérations de tablespace transportable InnoDB

Considération de performance : Sur un serveur avec des milliers de tables ouvertes, `FLUSH TABLES` acquiert brièvement un verrou global. Sur les systèmes à haute concurrence, cela peut provoquer un pic de latence notable. Préférez la forme spécifique à une table (`FLUSH TABLES tbl1, tbl2`) pour minimiser l’impact.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

C’est l’une des variantes de `FLUSH` les plus puissantes et potentiellement les plus perturbantes. Elle ferme toutes les tables ouvertes, vide le cache de requêtes et acquiert un verrou de lecture global qui empêche toute opération d’écriture sur toutes les bases de données. Le verrou persiste jusqu’à l’émission de `UNLOCK TABLES` ou la fin de la session.

Quand l’utiliser :

• Avant de prendre une sauvegarde physique avec des outils comme `mysqldump –single-transaction` (pour les bases de données InnoDB uniquement, cela est inutile — voir ci-dessous)
• Avant d’utiliser `mysqlpump` ou `xtrabackup` dans des environnements non-InnoDB
• Pour créer un snapshot cohérent à un instant donné sur des moteurs de stockage mixtes (InnoDB + MyISAM)

Écueil critique — bases de données InnoDB uniquement : Pour les bases de données utilisant exclusivement des tables InnoDB, `FTWRL` est presque jamais nécessaire. `mysqldump –single-transaction` ouvre une transaction en lecture répétable qui fournit un snapshot cohérent sans bloquer les écritures. L’utilisation de `FTWRL` dans ce scénario provoque des blocages d’écriture inutiles.

Risque de réplication : Si `FTWRL` est exécuté sur un réplica, il bloque le thread d’application SQL, provoquant une accumulation du retard de réplication pendant toute la durée du verrou. Surveillez toujours `Seconds_Behind_Master` après la libération du verrou.

Interaction avec les verrous de métadonnées : Dans MySQL 5.7+, `FTWRL` attend que toutes les transactions actives se terminent avant d’acquérir le verrou global. Sur un serveur très sollicité avec des transactions de longue durée, cette attente peut être indéfinie. Utilisez `SHOW PROCESSLIST` pour identifier les transactions bloquantes avant d’exécuter `FTWRL`.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL maintient un cache hôte qui enregistre l’historique des tentatives de connexion, y compris le nombre d’échecs d’authentification. Lorsqu’un hôte accumule plus de `max_connect_errors` échecs de connexion consécutifs, MySQL bloque toutes les connexions ultérieures depuis cet hôte jusqu’à ce que l’entrée du cache soit effacée.

Quand l’utiliser :

• Lorsqu’un hôte client légitime est bloqué pour avoir dépassé `max_connect_errors`
• Après la résolution d’un problème réseau ayant provoqué des échecs répétés de connexion TCP
• Après la modification d’enregistrements DNS affectant la façon dont le serveur résout les noms d’hôtes clients

Alternative MySQL 8.0 : Dans MySQL 8.0+, vous pouvez également tronquer directement la table du cache hôte :

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Cela produit le même résultat et est plus transparent dans les scripts automatisés.

Configuration proactive : Plutôt que de recourir à `FLUSH HOSTS` de manière réactive, définissez `max_connect_errors` à une valeur plus élevée (par exemple, `10000`) ou définissez `host_cache_size = 0` pour désactiver entièrement le cache hôte sur les réseaux internes de confiance.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Réinitialise la plupart des variables de statut de session et globales à zéro. Cela inclut des compteurs comme `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` et des centaines d’autres exposés via `SHOW STATUS` ou `performance_schema`.

Quand l’utiliser :

• Immédiatement avant un benchmark contrôlé pour établir une référence de mesure propre
• Après un changement de configuration (par exemple, ajustement de `innodb_buffer_pool_size`) pour isoler l’effet sur les métriques d’E/S
• Lors de la création de scripts de tests de régression de performance qui comparent les deltas de compteurs avant/après

Limitation importante : `FLUSH STATUS` ne réinitialise pas tous les compteurs. Les variables comme `Uptime`, `Uptime_since_flush_status` et certaines métriques internes InnoDB ne sont pas affectées. Pour une surveillance complète, utilisez directement les tables `performance_schema`, qui offrent une granularité par thread et par événement que `FLUSH STATUS` ne peut pas fournir.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` ferme et rouvre tous les fichiers journaux du serveur. MySQL 5.7.2+ a introduit la possibilité de vider des types de journaux spécifiques individuellement, ce qui est bien préférable en production.

Quand l’utiliser :

• Dans le cadre d’un script post-rotation `logrotate` pour signaler à MySQL d’ouvrir un nouveau fichier journal après la rotation de l’ancien
• Pour forcer un nouveau fichier journal binaire (équivalent à `FLUSH BINARY LOGS`), ce qui incrémente le numéro de séquence du journal binaire
• Avant d’archiver d’anciens journaux pour s’assurer que toutes les écritures en attente sont vidées sur le disque

Spécificités du journal binaire : `FLUSH BINARY LOGS` crée un nouveau fichier journal binaire et écrit un `Rotate_event` dans l’ancien fichier. C’est la méthode correcte pour segmenter les journaux binaires pour l’archivage de récupération à un instant donné (PITR). Le fichier journal binaire actuel et sa position peuvent être confirmés avec `SHOW MASTER STATUS` (MySQL 5.7) ou `SHOW BINARY LOG STATUS` (MySQL 8.4+).

Exemple d’intégration logrotate :

“`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;

“`

Avertissement de dépréciation : Le cache de requêtes MySQL a été déprécié dans MySQL 5.7.20 et entièrement supprimé dans MySQL 8.0. Si vous utilisez MySQL 8.0 ou une version ultérieure, cette commande n’existe pas.

Pour les environnements MySQL 5.6/5.7 où le cache de requêtes est encore actif :

• `FLUSH QUERY CACHE` défragmente la mémoire du cache de requêtes sans supprimer les résultats mis en cache
• `RESET QUERY CACHE` supprime entièrement tous les résultats de requêtes mis en cache

Quand l’utiliser (MySQL 5.6/5.7 uniquement) :

• Après une modification massive de données par lots qui invalide une partie significative des résultats mis en cache
• Lorsque `Qcache_free_blocks` est élevé par rapport à `Qcache_total_blocks`, indiquant une fragmentation
• Avant de désactiver le cache de requêtes (`SET GLOBAL query_cache_size = 0`) pour libérer proprement la mémoire

Alternative moderne : Sur MySQL 8.0+, utilisez le préchauffage du pool de tampons InnoDB (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) et `performance_schema` pour l’analyse au niveau des requêtes.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Réinitialise les compteurs de ressources par utilisateur suivis par la limitation de débit intégrée de MySQL. Ces compteurs appliquent les limites définies dans les instructions `CREATE USER` ou `GRANT` :

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

Quand l’utiliser :

• Lorsqu’un utilisateur a épuisé son quota de requêtes horaire et a besoin d’un accès immédiat restauré avant la réinitialisation naturelle du compteur à la prochaine heure
• Après avoir augmenté les limites de ressources d’un utilisateur et souhaitant que les nouvelles limites prennent effet immédiatement
• Lors du développement/test pour réinitialiser les quotas entre les exécutions de tests

Note : Cette commande réinitialise les compteurs pour tous les utilisateurs simultanément. Il n’y a pas de granularité par utilisateur au niveau de `FLUSH`. Si vous devez réinitialiser les compteurs d’un seul utilisateur, la seule option est de modifier son compte avec `ALTER USER` puis d’émettre `FLUSH USER_RESOURCES`.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Force tous les moteurs de stockage à vider leurs tampons d’écriture en attente vers leurs fichiers journaux respectifs. Pour InnoDB, cela signifie vider le tampon de journal redo (`innodb_log_buffer_size`) vers les fichiers journaux redo InnoDB sur le disque.

Quand l’utiliser :

• Avant de prendre une sauvegarde à froid des fichiers de données InnoDB pour assurer la cohérence du journal redo
• Lors du dépannage du moteur de stockage pour exclure les incohérences de données liées aux tampons
• Dans le cadre d’une liste de contrôle pré-maintenance avant l’arrêt du service MySQL

Contexte de durabilité InnoDB : Le paramètre `innodb_flush_log_at_trx_commit` d’InnoDB contrôle l’agressivité avec laquelle le journal redo est vidé à chaque validation de transaction. `FLUSH ENGINE LOGS` est un remplacement manuel qui force un vidage indépendamment de ce paramètre. Cela est utile dans les scénarios où vous avez besoin d’un point de contrôle de durabilité garanti sans valider une transaction.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Recharge le fichier de clé de chiffrement DES spécifié par l’option de démarrage du serveur `–des-key-file`. Ce fichier de clé était utilisé par les fonctions `DES_ENCRYPT()` et `DES_DECRYPT()`.

Avertissement de dépréciation : Les fonctions `DES_ENCRYPT()` et `DES_DECRYPT()` ont été dépréciées dans MySQL 5.7.6 et supprimées dans MySQL 8.0. Cette commande n’est donc pertinente que sur les installations MySQL 5.6/5.7 héritées.

Alternative de chiffrement moderne : Utilisez le chiffrement natif des données au repos de MySQL (chiffrement de tablespace InnoDB via `ALTER TABLE … ENCRYPTION='Y'`) combiné avec les plugins MySQL Keyring (`keyring_file`, `keyring_okv`, `keyring_aws`) pour les besoins de chiffrement en production.

Tableau comparatif des commandes FLUSH

Réplication et FLUSH : ce qui est répliqué

Toutes les commandes `FLUSH` ne sont pas répliquées vers les serveurs réplicas. Comprendre cette distinction est essentiel dans les topologies HA et de réplication :

Répliqué par défaut :

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (écrit comme un `Rotate_event` dans le journal binaire)
• `FLUSH USER_RESOURCES`

Non répliqué (local à la session ou explicitement exclu) :

• `FLUSH TABLES WITH READ LOCK` — jamais écrit dans le journal binaire
• `FLUSH STATUS` — affecte uniquement les compteurs du serveur local
• `FLUSH HOSTS` — cache hôte local uniquement
• `FLUSH ENGINE LOGS` — état du moteur local uniquement

Pour empêcher une commande `FLUSH` spécifique d’être répliquée même lorsqu’elle le serait normalement, utilisez le modificateur `LOCAL` ou `NO_WRITE_TO_BINLOG` :

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Cela est utile lors de la gestion indépendante des privilèges sur un réplica (par exemple, l’ajout d’utilisateurs de surveillance qui ne devraient pas exister sur le primaire).

Automatisation des opérations FLUSH avec mysqladmin

De nombreuses opérations `FLUSH` peuvent être déclenchées depuis le shell sans ouvrir une session client MySQL, ce qui est utile dans les tâches cron et les scripts de maintenance :

“`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

“`

Pour les environnements de production, stockez les identifiants dans `~/.my.cnf` avec `chmod 600` plutôt que de passer `-p` de manière interactive, ou utilisez le mécanisme `–login-path` de MySQL avec `mysql_config_editor`.

Considérations relatives à l’environnement d’hébergement

La capacité à exécuter des commandes `FLUSH` dépend fortement de l’environnement d’hébergement et du niveau d’accès à la base de données accordé. Sur un plan d’Hébergement VPS, vous disposez généralement d’un accès root complet à l’instance MySQL, ce qui signifie que vous pouvez exécuter n’importe quelle variante de `FLUSH`, modifier `my.cnf` et gérer la rotation des journaux directement. C’est l’environnement minimum recommandé pour tout travail sérieux d’administration de base de données.

Sur l’Hébergement Web Mutualisé, l’accès à la base de données est généralement limité à un utilisateur sans privilèges sans le privilège `RELOAD`, rendant la plupart des commandes `FLUSH` indisponibles. Si votre application nécessite la gestion des privilèges, le contrôle de la rotation des journaux ou des snapshots cohérents pour les sauvegardes, un environnement mutualisé sera un obstacle majeur.

Pour les charges de travail de base de données à haut débit — en particulier celles impliquant des opérations `FLUSH ENGINE LOGS` fréquentes ou de grands pools de tampons InnoDB — les Serveurs Dédiés fournissent le débit d’E/S et la bande passante mémoire nécessaires pour rendre ces opérations non perturbantes. Un `FLUSH TABLES WITH READ LOCK` sur un serveur avec 256 GB de données dans le pool de tampons prend sensiblement plus de temps que sur un serveur avec un stockage NVMe rapide et des canaux d’E/S dédiés.

Si vous gérez une instance MySQL avec un panneau de contrôle web, le VPS avec cPanel fournit un environnement géré où certaines opérations `FLUSH` (notamment la rotation des journaux et les rechargements de privilèges) sont gérées automatiquement par la couche de gestion de base de données du panneau de contrôle, réduisant le besoin d’intervention manuelle.

Pour les applications adossées à une base de données nécessitant un écosystème complet de panneau de contrôle, l’examen des Panneaux de Contrôle VPS disponibles vous aidera à identifier quel panneau s’intègre le mieux à votre flux de travail d’administration MySQL.

Liste de contrôle des points clés

Utilisez cette matrice de décision avant d’exécuter toute commande `FLUSH` en production :

• Avant `FLUSH TABLES WITH READ LOCK` : Confirmez qu’aucune transaction de longue durée n’est active (`SHOW PROCESSLIST`). Vérifiez si votre base de données est uniquement InnoDB — si c’est le cas, utilisez plutôt `–single-transaction`.
• Avant `FLUSH PRIVILEGES` : Confirmez que vous utilisez du DML brut sur les tables de droits. Si vous avez utilisé `GRANT`/`REVOKE`, cette commande est redondante.
• Avant `FLUSH LOGS` : Assurez-vous que votre script de rotation des journaux a déjà déplacé/renommé l’ancien fichier journal avant de signaler à MySQL de le rouvrir.
• Avant `FLUSH HOSTS` : Identifiez d’abord la cause première des échecs de connexion. Vider le cache hôte sans corriger le problème sous-jacent entraînera à nouveau le blocage de l’hôte.
• Sur MySQL 8.0+ : Supprimez tout appel à `FLUSH QUERY CACHE` ou `FLUSH DES_KEY_FILE` des scripts — ces commandes n’existent pas et provoqueront des erreurs.
• Dans les topologies de réplication : Utilisez `FLUSH LOCAL` ou `FLUSH NO_WRITE_TO_BINLOG` lorsque l’opération ne doit pas se propager aux réplicas.
• Pour l’automatisation : Utilisez les commandes `mysqladmin flush-*` dans les scripts plutôt que d’ouvrir des sessions client MySQL complètes.
• Audit des privilèges : Préférez les privilèges dynamiques MySQL 8.0 (`FLUSH_STATUS`, `FLUSH_TABLES`, etc.) au large privilège `RELOAD` pour les comptes de surveillance et de sauvegarde.

Foire aux questions

FLUSH PRIVILEGES doit-il être exécuté après chaque instruction GRANT ou REVOKE ?

Non. `GRANT`, `REVOKE`, `CREATE USER` et `DROP USER` rechargent automatiquement les tables de droits en mémoire. `FLUSH PRIVILEGES` n’est nécessaire qu’après des modifications DML directes sur les tables système `mysql` (par exemple, `UPDATE mysql.user SET …`).

FLUSH TABLES WITH READ LOCK peut-il provoquer une interruption de l’application ?

Oui. Il acquiert un verrou d’écriture global qui bloque toutes les opérations `INSERT`, `UPDATE`, `DELETE` et DDL sur chaque base de données du serveur. Sur un système OLTP très sollicité, même quelques secondes de `FTWRL` peuvent épuiser les pools de connexions et provoquer des erreurs d’application en cascade. Pour les bases de données InnoDB uniquement, utilisez `mysqldump –single-transaction` pour éviter cela entièrement.

FLUSH STATUS est-il équivalent à un redémarrage du serveur MySQL à des fins de benchmark ?

Non. `FLUSH STATUS` réinitialise la plupart des compteurs de statut mais ne vide pas le pool de tampons InnoDB, ne réinitialise pas les états de connexion ni n’affecte les statistiques accumulées par `performance_schema`. Pour un benchmark véritablement sur une ardoise vierge, un redémarrage du serveur combiné au vidage du pool de tampons est plus précis, bien qu’impraticable en production.

Pourquoi FLUSH HOSTS n’existe-t-il pas comme commande autonome dans certaines documentations MySQL 8.0 ?

`FLUSH HOSTS` fonctionne toujours dans MySQL 8.0, mais la méthode préférée est `TRUNCATE TABLE performance_schema.host_cache`, qui est plus explicite et peut être exécutée sans le privilège `RELOAD` si l’utilisateur dispose de `DELETE` sur `performance_schema`. Les deux produisent le même résultat.

Que se passe-t-il si FLUSH ENGINE LOGS est exécuté pendant une charge d’écriture maximale sur InnoDB ?

Cela force un vidage synchrone du tampon de journal InnoDB vers le disque, ce qui peut provoquer un bref blocage d’écriture si les fichiers journaux redo sont sur un stockage lent. Sur des serveurs équipés de NVMe, l’impact est généralement inférieur à la milliseconde. Sur des disques rotatifs ou un stockage SAN très sollicité, cela peut provoquer des pics de latence notables. Planifiez cette opération pendant les fenêtres de faible trafic lorsque cela est possible.