Le cache de requêtes stocke en mémoire les ensembles de résultats des instructions SELECT. Les requêtes identiques contournent ainsi entièrement l'analyse et l'exécution : le résultat est renvoyé directement depuis le cache. Cette approche réduit l'utilisation du processeur, diminue les IOPS et raccourcit les temps de réponse pour les charges de travail à forte proportion de lectures, peu sujettes aux écritures et dont les données sont stables. Pour les charges de travail intensives en écriture ou présentant des modèles de requêtes variés, la surcharge liée à l'invalidation du cache peut réduire le débit global. Testez avec votre charge de travail réelle avant d'activer cette fonctionnalité en production.
Quand utiliser le cache de requêtes
Le cache de requêtes offre les meilleures performances lorsque toutes les conditions suivantes sont réunies :
Les données des tables changent rarement ou sont statiques.
La même instruction SELECT s'exécute de manière répétée.
Les ensembles de résultats des requêtes sont inférieurs à 1 Mo.
Le cache de requêtes n'est pas toujours bénéfique. Pour les charges de travail comportant des écritures fréquentes dans les tables ou des requêtes variées, la surcharge liée à l'invalidation et au remplissage du cache peut réduire le débit global. Testez avec votre charge de travail réelle avant d'activer cette fonctionnalité en production.
Fonctionnement
ApsaraDB RDS for MySQL calcule une valeur de hachage pour chaque instruction SELECT reçue d'un client.
Si le hachage correspond à une entrée mise en cache, le résultat est renvoyé immédiatement sans analyse ni exécution de la requête.
En l'absence de correspondance, la requête s'exécute normalement et le hachage ainsi que le résultat sont stockés dans le cache.
Lorsqu'une table est modifiée, toutes les requêtes mises en cache qui font référence à cette table sont immédiatement invalidées et supprimées du cache.
Limitations
Les requêtes suivantes ne sont pas mises en cache :
Les requêtes qui ne diffèrent que par la casse, les espaces blancs, le contexte de base de données, la version du protocole ou le jeu de caractères sont traitées comme des requêtes distinctes et mises en cache séparément.
Les ensembles de résultats des sous-requêtes : seul l'ensemble de résultats final de la requête externe est mis en cache.
Les requêtes exécutées à l'intérieur d'une fonction stockée, d'une procédure stockée, d'un déclencheur ou d'un événement.
Les requêtes qui appellent l'une des fonctions non déterministes suivantes :
now(),curdate(),last_insert_id()ourand().Les requêtes qui font référence à des tables dans les bases de données
mysql,information_schemaouperformance_schema.Les requêtes qui font référence à des tables temporaires.
Les requêtes qui génèrent des avertissements.
Les requêtes contenant
SELECT … LOCK IN SHARE MODE,SELECT … FOR UPDATEouSELECT * FROM … WHERE AUTOINCREMENT_COL IS NULL.Les requêtes qui font référence à une variable définie par l'utilisateur.
Les requêtes utilisant l'indicateur
SQL_NO_CACHE.
Configuration du cache de requêtes
Définissez ces trois paramètres dans la console ApsaraDB RDS :
| Paramètre | Valeur par défaut | Description |
|---|---|---|
query_cache_type |
— | Contrôle si le cache est actif. 0 = désactivé ; 1 = activé (les requêtes utilisant SELECT SQL_NO_CACHE sont exclues) ; 2 = à la demande uniquement (seules les requêtes SELECT SQL_CACHE sont mises en cache). |
query_cache_size |
3 Mo | Mémoire totale allouée au cache, en octets. Doit être un multiple de 1024. |
query_cache_limit |
1 Mo | Taille maximale de l'ensemble de résultats pour une seule requête mise en cache, en octets. Les résultats supérieurs à cette valeur ne sont pas mis en cache. |
Dans le volet de navigation de gauche, cliquez sur Parameters. Dans la liste des paramètres, recherchez query_cache_type et modifiez sa valeur selon vos besoins. La modification ne prend effet qu'après le redémarrage de l'instance. Vous pouvez également ajuster les paramètres connexes tels que query_cache_limit (valeurs valides : 1 à 1048576) et query_cache_size (valeurs valides : 0 à 104857600). Cliquez sur l'icône d'information située à côté d'un paramètre pour afficher sa description.
La modification de query_cache_type déclenche un redémarrage automatique de l'instance RDS. Si vous définissez query_cache_size sur une valeur qui n'est pas un multiple de 1024, la console renvoie l'erreur The specified parameter is invalid, avec le code d'erreur InvalidParameters.Malformed.
Activation et désactivation du cache
Le cache est activé lorsque query_cache_size > 0 et que query_cache_type est défini sur 1 ou 2.
Le cache est désactivé lorsque query_cache_size = 0 ou que query_cache_type = 0.
Recommandations
Évitez de définir
query_cache_sizesur une valeur trop élevée. Un cache surdimensionné non seulement prive les autres structures mémoire de l'instance de ressources, mais augmente également la surcharge liée aux recherches dans le cache. Commencez par une valeur comprise entre 10 Mo et 100 Mo selon le type de votre instance, puis ajustez-la en fonction de l'utilisation observée.Pour activer ou désactiver le cache de requêtes, ajustez la valeur de
query_cache_sizeplutôt que celle dequery_cache_type, car les modifications dequery_cache_typene prennent effet qu'après un redémarrage de l'instance.Le cache de requêtes n'est avantageux que pour des charges de travail spécifiques. Effectuez des tests approfondis avec votre charge de travail réelle avant de l'activer afin d'éviter toute dégradation des performances ou d'autres problèmes.
Surveillance et vérification des performances du cache
Vérification des statistiques du cache
Exécutez l'instruction suivante pour vérifier l'utilisation du cache :
SHOW GLOBAL STATUS LIKE 'Qcache%';
La sortie inclut les variables d'état suivantes :
| Variable | Description |
|---|---|
Qcache_hits |
Nombre de requêtes servies depuis le cache |
Qcache_inserts |
Nombre de requêtes ajoutées au cache |
Qcache_not_cached |
Nombre de requêtes qui n'ont pas pu être mises en cache |
Qcache_queries_in_cache |
Nombre de requêtes actuellement présentes dans le cache |
Exemple de sortie :
mysql>show global status like 'Qca%';
+-------------------------+------------+
| Variable_name | Value |
+-------------------------+------------+
| Qcache_free_blocks | 2763 |
| Qcache_free_memory | 10115160 |
| Qcache_hits | 365589713 |
| Qcache_inserts | 612280336 |
| Qcache_lowmem_prunes | 1257159 |
| Qcache_not_cached | 1805250864 |
| Qcache_queries_in_cache | 9318 |
| Qcache_total_blocks | 22409 |
+-------------------------+------------+
Vérification via la console ApsaraDB RDS
Dans le volet de navigation de gauche, choisissez Autonomy Service (formerly CloudDBA) > Performance Trends. Consultez le graphique MySQL CPU/Memory Utilization et assurez-vous que l'utilisation du processeur et de la mémoire reste dans la plage normale.