- 1 1. Introduction
- 2 2. Architecture du cache selon la version de MySQL
- 3 3. Comment nettoyer le Query Cache (pour MySQL 5.7 et antérieur)
- 4 4. Vidage du cache de tables et caches associés
- 5 5. Comment « vider » le pool de tampons InnoDB (pour MySQL 8.0)
- 6 6. Contrôle du cache à l’aide d’outils tiers
- 7 7. Risques et précautions
- 8 8. Résumé de la procédure (Table de référence rapide)
- 9 9. FAQ (Foire aux questions)
- 9.1 Q1. Le cache de requêtes et le pool de tampons InnoDB sont-ils identiques ?
- 9.2 Q2. De combien la performance chute‑t‑elle après avoir vidé le cache ?
- 9.3 Q3. Est‑il sûr de vider les caches dans un environnement de production ?
- 9.4 Q4. Puis‑je activer le cache de requêtes dans MySQL 8.0 ?
- 9.5 Q5. Puis‑je vider les caches dans des services cloud tels qu’AWS RDS ou Cloud SQL ?
- 9.6 Q6. Existe‑t‑il un moyen de vider les caches automatiquement ?
- 10 10. Résumé et meilleures pratiques
1. Introduction
MySQL est l’une des bases de données les plus largement utilisées dans les services web et les systèmes du monde entier. Pour améliorer les performances et réduire la charge du serveur, MySQL propose divers mécanismes de mise en cache. Cependant, en environnements de développement et de production, des problèmes tels que « les dernières données ne sont pas reflétées à cause du cache » ou « un cache ancien interfère avec les changements de configuration ou le débogage » ne sont pas rares.
Dans de telles situations, nettoyer (supprimer ou réinitialiser) le cache MySQL devient extrêmement utile. Par exemple, cette opération est efficace lorsque vous souhaitez vérifier immédiatement les données mises à jour dans un environnement de test, nettoyer le cache avant de prendre un instantané, ou réinitialiser de force des données en cache restées par inadvertance.
Cet article s’adresse aux personnes intéressées par le « mysql cache clear » et explique les caractéristiques ainsi que les méthodes de nettoyage de chaque type de cache de manière claire et compréhensible. De plus, nous abordons les différences de spécifications de cache selon la version de MySQL, les considérations opérationnelles, les questions fréquentes et leurs solutions.
En comprenant correctement le fonctionnement du cache et la manière de le nettoyer, vous pourrez utiliser MySQL de façon plus stable et plus efficace.
2. Architecture du cache selon la version de MySQL
Les fonctionnalités de mise en cache de MySQL diffèrent sensiblement selon la version. En particulier, la philosophie de conception du cache a changé entre MySQL 5.7 et les versions antérieures d’une part, et MySQL 8.0 et les versions ultérieures d’autre part. Ici, nous résumons les principaux types de caches utilisés dans MySQL ainsi que les différences selon les versions.
2.1 Cache de requêtes (MySQL 5.7 et antérieur)
Dans MySQL 5.7 et les versions antérieures, une fonctionnalité appelée « Query Cache » était incluse par défaut. Ce mécanisme stocke les instructions SELECT exécutées et leurs jeux de résultats en mémoire, permettant à la même requête de renvoyer rapidement les résultats si elle est exécutée à nouveau. Bien qu’il puisse être efficace dans des services web simples, dans des environnements où les données sont fréquemment mises à jour, le cache est souvent invalidé, ce qui peut au contraire entraîner une dégradation des performances.
2.2 Pool de tampons InnoDB (MySQL 5.5–8.0)
Depuis MySQL 5.5, et surtout avec MySQL 8.0, le « InnoDB Buffer Pool » est devenu le mécanisme de mise en cache central. Cette fonctionnalité permet au moteur de stockage InnoDB de conserver les données et les informations d’index en mémoire afin de réduire les I/O disque et d’améliorer les performances. Contrairement au Query Cache, le pool de tampons met en cache les données au niveau des tables ou des lignes, offrant une performance stable même dans les systèmes à grande échelle ou les environnements à mises à jour fréquentes.
2.3 Cache de tables et autres caches
En outre, MySQL comprend plusieurs autres mécanismes de mise en cache tels que le « Table Cache (table_open_cache) », le « Thread Cache » et le « User Variable Cache ». En particulier, le Table Cache gère efficacement les tables fréquemment accédées et est disponible dans toutes les versions.
2.4 Résumé des spécifications du cache par version
- MySQL 5.7 et antérieur : Query Cache + InnoDB Buffer + Table Cache
- MySQL 8.0 et ultérieur : Query Cache supprimé, InnoDB Buffer Pool principal, Table Cache maintenu
Comme indiqué ci‑dessus, les types et rôles des caches évoluent selon la version de MySQL. Il est donc important de comprendre les mesures appropriées pour la version que vous utilisez.
3. Comment nettoyer le Query Cache (pour MySQL 5.7 et antérieur)
Si vous utilisez MySQL 5.7 ou une version antérieure, la fonctionnalité « Query Cache » est souvent activée. Dans cette section, nous expliquons le fonctionnement du Query Cache, comment le nettoyer, et les précautions importantes à prendre.
3.1 Qu’est‑ce que le Query Cache ?
Le Query Cache stocke les instructions SELECT et leurs jeux de résultats en mémoire, et lorsqu’une même requête est exécutée à nouveau, il renvoie immédiatement le résultat depuis le cache. Il est surtout efficace pour les sites web ou les petites applications qui consultent fréquemment des données statiques. Cependant, dans les environnements où les données sont mises à jour souvent, le cache devient moins efficace, il faut donc faire preuve de prudence.
3.2 Commandes pour nettoyer le Query Cache
Pour nettoyer le Query Cache, les deux commandes suivantes sont principalement utilisées.
RESET QUERY CACHE;Cela supprime toutes les entrées du cache de requêtes. Comme toutes les requêtes et jeux de résultats mis en cache sont supprimés, cela est utile lorsque vous souhaitez éliminer complètement les effets du cache.FLUSH QUERY CACHE;Cela supprime uniquement les entrées « inutilisées » du cache. C’est approprié lorsque vous voulez nettoyer seulement les anciennes entrées déjà invalidées.
3.3 Comment exécuter les commandes
Exécutez les commandes depuis un client MySQL ou un outil d’administration (tel que phpMyAdmin) comme suit.
RESET QUERY CACHE;
Ou :
FLUSH QUERY CACHE;
Certains cas nécessitent des privilèges. Si vous obtenez une erreur d’autorisation, relancez la commande avec des privilèges administratifs (comme root).
3.4 Précautions et bonnes pratiques
- Vider le cache de requêtes affecte l’ensemble du serveur, il faut donc l’exécuter avec précaution en environnement de production.
- Après avoir vidé le cache, les performances peuvent diminuer temporairement.
- Dans MySQL 8.0 et versions ultérieures, la fonctionnalité de cache de requêtes a été supprimée, ces commandes ne peuvent donc pas être utilisées.
En vidant efficacement le cache de requêtes, vous pouvez éviter les effets de cache non intentionnels et permettre une vérification précise des dernières données et du comportement correct.
4. Vidage du cache de tables et caches associés
MySQL comprend divers mécanismes de mise en cache en plus du cache de requêtes. En particulier, le « Table Cache » (cache de tables) est utilisé pour gérer efficacement les tables fréquemment accédées. Ce chapitre explique comment vider le cache de tables et les caches associés.
4.1 Qu’est‑ce que le cache de tables ?
Le cache de tables (table_open_cache) est un mécanisme où MySQL garde les tables ouvertes en interne afin d’éviter de les charger à chaque accès depuis le disque. Il contribue à améliorer les performances lorsque de nombreux utilisateurs ou applications accèdent simultanément à la base de données.
4.2 Comment vider le cache de tables
Pour vider le cache de tables, vous utilisez principalement la commande FLUSH TABLES.
FLUSH TABLES;
Lorsque vous exécutez cette commande, MySQL ferme toutes les tables actuellement ouvertes, puis les rouvre au besoin. Cela réinitialise le contenu du cache de tables et est utile pour appliquer des modifications de définition de tables ou résoudre des problèmes liés à la mise en cache.
4.3 Vidage d’autres caches associés
MySQL fournit des commandes pour vider divers caches en plus du cache de tables. Voici quelques exemples.
- FLUSH TABLES WITH READ LOCK; Ferme toutes les tables et les place en état verrouillé, ce qui peut être utilisé pour les sauvegardes et opérations similaires.
- FLUSH PRIVILEGES; Vide le cache des tables de privilèges (informations d’utilisateurs et de privilèges) et applique immédiatement les modifications de privilèges.
- FLUSH STATUS; Réinitialise les statistiques de diverses variables d’état (consultables via SHOW STATUS, etc.).
4.4 Vidage de plusieurs caches en une fois
Comme la commande de vidage diffère selon le type de cache, si vous souhaitez réinitialiser plusieurs caches simultanément, exécutez chaque commande séquentiellement. Par exemple, dans un environnement de développement ou de test où vous voulez « réinitialiser tous les caches en une fois », vous pouvez combiner les commandes ainsi :
FLUSH TABLES;
RESET QUERY CACHE;
(Ceci concerne MySQL 5.7 et antérieur ; RESET QUERY CACHE n’est pas disponible dans MySQL 8.0 et versions ultérieures.)
4.5 Remarques
- Vider le cache de tables peut temporairement affecter les performances sur les systèmes avec de nombreuses tables ouvertes.
- En environnements de production, confirmez à l’avance l’étendue de l’impact avant d’exécuter ces commandes.
- Selon les privilèges, certaines commandes peuvent ne pas être exécutables. Si une erreur apparaît, relancez la commande avec un utilisateur disposant des privilèges appropriés.
En vidant correctement le cache de tables et les caches associés, vous pouvez rendre les opérations MySQL plus stables et simplifier le dépannage.
5. Comment « vider » le pool de tampons InnoDB (pour MySQL 8.0)
Dans MySQL 8.0 et versions ultérieures, la fonctionnalité de cache de requêtes a été supprimée, et le « InnoDB Buffer Pool » joue le rôle central du caching. Cependant, contrairement au cache de requêtes traditionnel, le InnoDB Buffer Pool ne peut pas être « vidé » avec une seule commande. Ce chapitre explique les approches pratiques pour vider efficacement le InnoDB Buffer Pool et les précautions importantes.
5.1 Qu’est-ce que le InnoDB Buffer Pool ?
Le InnoDB Buffer Pool est un mécanisme qui met en cache les données des tables, les index et les pages de données fréquemment accédées en mémoire afin de réduire les entrées/sorties disque et d’améliorer les performances. Dans MySQL 8.0, ce pool de tampons est le composant clé pour l’optimisation des performances.
5.2 Comment vider le Buffer Pool et méthodes alternatives
Il n’existe aucune commande MySQL standard qui « vide » directement le InnoDB Buffer Pool. Les principales approches sont les suivantes.
- Redémarrer le serveur MySQL Arrêter et redémarrer le serveur initialise le contenu du pool de tampons, effaçant effectivement toutes les données en cache. Cependant, une opération prudente est requise en environnement de production.
- Modifier temporairement la taille du Buffer Pool En définissant
innodb_buffer_pool_sizeà une valeur plus petite et en redémarrant MySQL, puis en la restaurant à la valeur originale et en redémarrant à nouveau, vous pouvez également initialiser le pool de tampons. - Vider individuellement les pages du Buffer Pool La commande suivante écrit les pages modifiées (dirty) du pool de tampons sur le disque, mais elle ne vide pas complètement le cache lui‑même.
FLUSH TABLES;
5.3 Exemple pratique de vidage du Buffer Pool
Par exemple, dans un environnement de test où vous souhaitez vider le buffer pool, suivez ces étapes :
- Arrêtez le serveur MySQL.
- Ajustez
innodb_buffer_pool_sizesi nécessaire. - Démarrez le serveur MySQL.
Cela réinitialise le pool de tampons en mémoire, aboutissant à un état où toutes les informations en cache ont été supprimées.

5.4 Précautions et conseils opérationnels
- L’initialisation du buffer pool (via le redémarrage du serveur) interrompt temporairement le service, il est donc essentiel de coordonner et de notifier à l’avance en environnements de production.
- Immédiatement après le vidage du buffer pool, l’accès disque augmente et les performances peuvent temporairement se dégrader. Soyez prudent dans les systèmes à fort trafic.
- Si le redémarrage n’est pas possible, préparez un environnement de test ou de développement séparé pour les travaux de vérification.
En comprenant parfaitement le fonctionnement du InnoDB Buffer Pool et en effectuant les réinitialisations aux moments appropriés, vous pouvez garantir des opérations stables même dans les environnements MySQL 8.0 et ultérieurs.
6. Contrôle du cache à l’aide d’outils tiers
La gestion du cache MySQL peut être rendue plus efficace et plus facile à visualiser en utilisant des outils et utilitaires tiers en plus des commandes standard. Ici, nous présentons des outils représentatifs et des cas d’utilisation pratiques.
6.1 Surveillance et optimisation du cache avec MySQLTuner
« MySQLTuner » est un outil de diagnostic bien connu qui analyse l’état d’un serveur MySQL et fournit automatiquement des recommandations pour améliorer les performances. Il présente également les statistiques d’utilisation et les valeurs de configuration recommandées pour les caches tels que le Query Cache, le InnoDB Buffer Pool et le Table Cache.
Comment utiliser MySQLTuner :
- Installez MySQLTuner sur votre serveur (distribué sous forme de script Perl).
- Exécutez la commande suivante pour lancer le diagnostic.
perl mysqltuner.pl
- Les résultats affichent des éléments de diagnostic tels que « Query cache » et « InnoDB Buffer Pool », ainsi que des ajustements de paramètres recommandés ou des suggestions de désactivation des fonctionnalités de cache inutiles si besoin.
6.2 Utilisation du Percona Toolkit
« Percona Toolkit » est un ensemble complet d’outils utiles pour les opérations MySQL et l’analyse des performances. Par exemple, il peut générer des rapports sur l’état du buffer pool et l’utilisation du cache des tables avec une seule commande, ce qui le rend pratique pour la surveillance d’environnements à grande échelle.
6.3 Exemples d’outils de surveillance et de visualisation
- phpMyAdmin / MySQL Workbench Ces outils de gestion vous permettent de vérifier l’état actuel du cache et d’exécuter certaines commandes FLUSH via une interface graphique. Ils sont conviviaux et adaptés à la surveillance et aux tâches mineures de contrôle du cache.
- Zabbix ou Prometheus Ces outils surveillent l’utilisation de la mémoire du serveur et l’utilisation du pool de tampons InnoDB, permettant une visualisation en temps réel du comportement du cache et des contraintes de ressources. Ils sont utiles pour la détection précoce d’anomalies et les alertes automatisées.
6.4 Précautions lors de l’utilisation d’outils tiers
- L’exécution de ces outils peut nécessiter des privilèges administratifs ou des permissions spécifiques d’utilisateur MySQL.
- Avant d’utiliser les outils en production, il est recommandé de vérifier leur comportement dans un environnement de test.
- Certains outils peuvent augmenter temporairement la charge du serveur, il est donc conseillé d’effectuer les opérations pendant les heures creuses.
En exploitant efficacement les outils tiers, vous pouvez visualiser l’état du cache de MySQL et effectuer un nettoyage et une optimisation en temps opportun.
7. Risques et précautions
Bien que la purge des caches MySQL soit extrêmement utile, la réaliser au mauvais moment ou de la mauvaise manière peut entraîner des problèmes inattendus ou une dégradation des performances. Ce chapitre explique les risques et les précautions que vous devez comprendre avant de purger les caches.
7.1 Impact sur les performances
Après la purge des caches, la charge du serveur MySQL peut temporairement augmenter. En particulier, si de grands caches tels que le pool de tampons InnoDB ou le cache de tables sont vidés, toutes les données en mémoire sont perdues. En conséquence, des entrées/sorties disque se produisent pour chaque requête client, ce qui peut réduire considérablement la vitesse de réponse.
7.2 Soyez extrêmement prudent dans les environnements de production
Lors de la purge des caches dans un système de production, une prudence particulière est requise. Exécuter des commandes pendant les heures de trafic maximal peut nuire aux performances globales du système et entraîner des interruptions de service ou des réponses lentes. Dans les environnements de production, une validation suffisante, une coordination préalable, des sauvegardes et un timing soigneux sont essentiels.
7.3 Prenez en compte les mises à jour de données et la cohérence
Selon le moment de la purge du cache, des incohérences de données ou un comportement inattendu de l’application peuvent survenir. Par exemple, si les structures de tables sont modifiées ou qu’un traitement par lots est en cours lorsque les caches sont vidés, les résultats des requêtes ou la logique de l’application peuvent se comporter de manière imprévisible.
7.4 Évitez les purges de cache inutiles
Évitez la pratique du « juste vider le cache pour l’instant ». Les caches MySQL sont conçus pour réduire la charge du serveur et améliorer la vitesse de traitement. Un vidage fréquent peut au contraire rendre les performances instables. Assurez-vous toujours que la purge du cache n’est effectuée que lorsqu’elle est réellement nécessaire.
7.5 Considérations relatives aux permissions et à la sécurité
Les commandes et outils de purge de cache nécessitent des privilèges suffisants. Les exécuter avec des utilisateurs trop privilégiés peut risquer d’affecter d’autres paramètres ou données critiques. Suivez les meilleures pratiques de sécurité, comme l’utilisation d’utilisateurs aux privilèges minimaux et l’enregistrement des journaux d’exécution.
En comprenant ces risques et précautions, vous pouvez maintenir les performances et la stabilité de MySQL de manière sûre et efficace.
8. Résumé de la procédure (Table de référence rapide)
Ci-dessous se trouve une table de référence rapide résumant les procédures de purge du cache MySQL présentées jusqu’à présent, organisée par type de cache et version de MySQL. Utilisez cette table lors des opérations ou du dépannage.
| Target Operation | MySQL Version | Example Command / Method | Effect |
|---|---|---|---|
| Query Cache | 5.7 and earlier | RESET QUERY CACHE; FLUSH QUERY CACHE; | Delete all Query Cache entries or only unused entries |
| Table Cache | All versions | FLUSH TABLES; | Clear cache of open tables |
| Privilege Cache | All versions | FLUSH PRIVILEGES; | Clear privilege information cache |
| Status Statistics | All versions | FLUSH STATUS; | Reset SHOW STATUS statistics |
| InnoDB Buffer | 8.0 and later | Server restart Temporary buffer pool size adjustment | Initialize buffer pool (memory cache) |
| Comprehensive Cache | All versions | Execute multiple commands above in combination | Clear cache-related components comprehensively |
Explication rapide :
- RESET QUERY CACHE; Réinitialise l’intégralité du cache de requêtes (MySQL 5.7 et versions antérieures uniquement).
- FLUSH QUERY CACHE; Supprime uniquement les entrées du cache de requêtes invalidées et inutilisées.
- FLUSH TABLES; Ferme toutes les tables ouvertes une fois et réinitialise le cache de tables.
- FLUSH PRIVILEGES; Applique immédiatement les modifications des privilèges utilisateur.
- FLUSH STATUS; Réinitialise diverses statistiques d’état, utile lors de l’analyse des performances.
- Initialiser le pool de tampons InnoDB Réalisé indirectement via le redémarrage du serveur ou la modification de
innodb_buffer_pool_size(MySQL 8.0 et versions ultérieures).
En utilisant ce tableau, vous pouvez rapidement sélectionner la procédure d’effacement du cache appropriée en fonction de votre environnement et de vos objectifs.
9. FAQ (Foire aux questions)
Voici les questions courantes concernant l’effacement des caches MySQL, souvent posées par les opérateurs et les développeurs, ainsi que leurs réponses. Utilisez-les comme référence pratique.
Q1. Le cache de requêtes et le pool de tampons InnoDB sont-ils identiques ?
A. Non, ce sont des mécanismes différents. Le cache de requêtes stocke les ensembles de résultats des requêtes SQL elles‑elles, tandis que le pool de tampons InnoDB conserve les données des tables et les index en mémoire. Leurs objectifs et leurs mécanismes internes sont totalement différents, il ne faut donc pas les confondre.
Q2. De combien la performance chute‑t‑elle après avoir vidé le cache ?
A. La performance diminue temporairement. En particulier dans les environnements avec de gros caches, l’accès au disque augmente lors de la première exécution des requêtes, ce qui peut réduire considérablement la vitesse de réponse. Cependant, la performance se rétablit progressivement à mesure que le cache se reconstruit.
Q3. Est‑il sûr de vider les caches dans un environnement de production ?
A. Ce n’est généralement pas recommandé. Vider les caches en production affecte directement la performance et la stabilité du service. Des tests suffisants, une préparation adéquate et un ajustement du timing sont essentiels. Si vous devez le faire, assurez‑vous d’informer les parties prenantes à l’avance et de réaliser des sauvegardes.
Q4. Puis‑je activer le cache de requêtes dans MySQL 8.0 ?
A. Non. La fonctionnalité de cache de requêtes a été complètement supprimée dans MySQL 8.0. Si vous avez besoin de cette fonctionnalité, vous devez utiliser MySQL 5.7 ou une version antérieure.
Q5. Puis‑je vider les caches dans des services cloud tels qu’AWS RDS ou Cloud SQL ?
A. Oui, mais il peut y avoir des restrictions selon le service. Par exemple, certaines commandes FLUSH ou opérations de redémarrage du serveur peuvent être limitées dans RDS. Vérifiez toujours la documentation officielle et les consignes de la console de gestion avant de procéder.
Q6. Existe‑t‑il un moyen de vider les caches automatiquement ?
A. Vous pouvez automatiser l’exécution périodique des commandes FLUSH à l’aide de scripts shell ou de tâches cron. Cependant, il n’est pas recommandé de vider les caches fréquemment. N’utilisez l’automatisation que lorsque cela est nécessaire, par exemple lors d’une maintenance planifiée.
En consultant ces FAQ à l’avance, vous pouvez lever les préoccupations opérationnelles et exécuter les tâches de vidage du cache MySQL avec davantage de confiance.
10. Résumé et meilleures pratiques
Effacer les caches MySQL est une opération essentielle dans les environnements de développement et de production. Dans cet article, nous avons présenté les types de caches selon la version de MySQL, les méthodes de vidage, les précautions et les questions fréquentes. À partir de ces informations, voici les principales bonnes pratiques.
10.1 Utilisez activement le vidage du cache dans les environnements de test
Lors des tests, de la validation et du débogage, il est souvent nécessaire de supprimer les effets du cache afin de vérifier le comportement réel. Utilisez les commandes de vidage du cache de manière appropriée pour améliorer la reproductibilité et la précision des tests.
10.2 Opérez avec prudence en production
Vider les caches en production peut avoir un impact significatif sur la performance et la stabilité. Évaluez toujours l’étendue de l’impact et le moment d’exécution avant d’agir. Informez les parties concernées et effectuez des sauvegardes si nécessaire. Évitez de vider les caches de façon indiscriminée — ne le faites que lorsqu’il est réellement nécessaire.
10.3 Comprenez correctement les versions et les types de caches
Comme les mécanismes de cache de MySQL diffèrent selon la version, il est important de comprendre quels caches et quelles méthodes de vidage s’appliquent à votre environnement. Chaque type de cache possède des commandes et des portées d’impact différentes, choisissez donc la procédure la plus appropriée en fonction de votre objectif.
10.4 Exploitez les outils tiers et de surveillance
Des outils tels que MySQLTuner et Percona Toolkit permettent d’évaluer objectivement l’état du serveur et l’utilisation du cache. Utilisez des outils de visualisation et d’automatisation pour soutenir les opérations avancées et prévenir les problèmes de manière proactive.
10.5 Conclusion
Lorsqu’elle est correctement exécutée, la purge du cache MySQL contribue grandement à la stabilité des opérations de base de données, au dépannage et à l’amélioration des performances. Utilisez ce guide pour appliquer les méthodes de purge du cache les plus appropriées à votre environnement et obtenir une gestion du système de haute qualité.


