Le Fast Query Cache est un moteur de cache natif PolarDB qui améliore le nombre de requêtes par seconde (QPS) pour les charges de travail intensives en lecture. Il met en cache les jeux de résultats et répond aux requêtes répétées directement depuis la mémoire, sans réanalyser, réoptimiser ni réexécuter le code SQL.
Fonctionnement
Lors de l'exécution d'une requête, le Fast Query Cache stocke son jeu de résultats. Si cette même requête s'exécute à nouveau avant toute modification des données sous-jacentes, le résultat mis en cache est retourné immédiatement. Le cache s'invalide automatiquement dès que les données changent.
Le Fast Query Cache résout trois limitations majeures du cache de requêtes natif MySQL :
| Limitation | Solution apportée par le Fast Query Cache |
|---|---|
| Goulot d'étranglement lié à la concurrence : le cache de requêtes natif MySQL utilise un verrou global qui sérialise les accès en cas de forte concurrence. Les performances se dégradent davantage à mesure que le nombre de cœurs CPU augmente. | Le Fast Query Cache remplace le verrou global par un mécanisme de synchronisation sans verrou. Plusieurs cœurs CPU traitent ainsi les requêtes en parallèle sans contention. |
| Récupération de mémoire inefficace : le cache natif MySQL préalloue un bloc mémoire fixe qu'il ne peut pas libérer efficacement, entraînant une sous-utilisation de la mémoire. | Grâce à l'allocation dynamique de mémoire, le Fast Query Cache libère immédiatement les entrées invalides. L'utilisation de la mémoire reste ainsi optimale et flexible. |
| Baisse de performance en cas de faible taux de réussite : le cache natif MySQL ajoute une surcharge susceptible de ralentir les requêtes lorsque le taux de réussite du cache est faible. | Le Fast Query Cache surveille les taux de réussite en temps réel et ajuste dynamiquement sa politique de mise en cache. Il garantit des performances stables, même si le taux de réussite diminue ou si la charge de travail mélange lectures et écritures. |
Le cache de requêtes natif a été supprimé dans MySQL 8.0. Le Fast Query Cache le remplace et a été conçu spécifiquement pour PolarDB.
Versions prises en charge
Le Fast Query Cache est disponible sur les versions de révision suivantes de PolarDB for MySQL :
| Version de PolarDB | Version de révision minimale |
|---|---|
| PolarDB for MySQL 8.0 | 8.0.1.1.5 |
| PolarDB for MySQL 5.7 | 5.7.1.0.15 |
| PolarDB for MySQL 5.6 | 5.6.1.0.29 |
Pour vérifier la version de révision de votre cluster, consultez Interroger la version du moteur.
Cas d'utilisation du Fast Query Cache
Le Fast Query Cache offre les meilleurs avantages dans les situations suivantes :
Votre charge de travail est dominée par les lectures, avec un volume de lectures nettement supérieur à celui des écritures.
Les requêtes se répètent fréquemment, maintenant un taux de réussite du cache élevé (supérieur à environ 60 %).
Un grand nombre de requêtes de lecture simultanées tirent parti du traitement en mémoire.
Évitez d'activer le Fast Query Cache, ou définissez-le en mode DEMAND, dans les cas suivants :
Le débit d'écriture est élevé ou les données changent fréquemment. Dans ce scénario, l'activation du cache peut réduire le QPS d'environ 2 %.
Peu de requêtes se répètent, ce qui maintient le taux de réussite du cache à un niveau bas.
Activation du Fast Query Cache
Chaque spécification de cluster PolarDB inclut une capacité mémoire préallouée pour le Fast Query Cache. Pour activer cette fonctionnalité, définissez le paramètre approprié dans la configuration de votre cluster ou de votre nœud. Pour plus d'informations, consultez Spécifier les paramètres du cluster et du nœud.
| Version de PolarDB | Paramètre | Valeur à définir |
|---|---|---|
| PolarDB for MySQL 8.0 | loose_query_cache_type |
ON |
| PolarDB for MySQL 5.6 ou 5.7 | query_cache_type |
1 |
Gestion du Fast Query Cache
Contrôle du comportement de mise en cache avec loose_query_cache_type
Utilisez loose_query_cache_type pour déterminer si le Fast Query Cache doit être toujours actif, optionnel ou désactivé. Définissez ce paramètre au niveau du cluster, ou remplacez-le au niveau de la session pour des charges de travail spécifiques.
| Valeur | Comportement |
|---|---|
OFF (par défaut) |
Le Fast Query Cache est désactivé. |
ON |
Le Fast Query Cache est actif pour toutes les requêtes. Ajoutez SQL_NO_CACHE à une requête pour exclure celle-ci de la mise en cache. |
DEMAND |
Le Fast Query Cache est inactif par défaut. Ajoutez SQL_CACHE à une requête pour la mettre en cache. |
Choisissez le mode correspondant à votre charge de travail :
Débit d'écriture élevé ou mises à jour fréquentes des données : utilisez
OFFpour éviter la surcharge liée à la mise en cache.Nombreuses requêtes lentes répétées ou taux de réussite du cache élevé : privilégiez
ONafin de maximiser les gains de QPS.Charge de travail mixte où seules certaines requêtes bénéficient du cache : optez pour
DEMAND, puis ajoutezSQL_CACHEaux requêtes fréquemment répétées :
SELECT SQL_CACHE id, name FROM customer;Gestion de la durée de vie des entrées de cache avec query_cache_lease_time
Le Fast Query Cache récupère la mémoire de manière dynamique. Si un jeu de résultats mis en cache n'est pas référencé pendant la durée spécifiée par query_cache_lease_time (en secondes), l'entrée de cache est libérée et sa mémoire récupérée.
La valeur par défaut est de 3600 secondes (1 heure).
Tests de performance
Le test de performance suivant illustre l'impact sur le QPS de l'activation du Fast Query Cache (PolarDB-QC) par rapport à sa désactivation (QC-OFF).
Environnement de test :
| Paramètre | Valeur |
|---|---|
| Cluster | PolarDB for MySQL 8.0 Cluster Edition, 8 cœurs, 64 Go de mémoire |
| Mémoire du cache | 4 Go |
| Outil de test | Sysbench |
| Données de test | 25 tables × 40 000 lignes ; 25 tables × 400 000 lignes |
| Cas de test | oltp_read_only, oltp_point_select, oltp_read_write avec rand-type = special ou uniform |
Tous les résultats concernent uniquement le nœud principal.
Synthèse des résultats :
| Scénario | Taux de réussite du cache | Variation du QPS |
|---|---|---|
| Taux de réussite élevé (Cas 1, 3, 4, 5, 7) | 63 % – 99 % | +53 % à +106 % |
| Taux de réussite faible (Cas 2, 6) | Faible | -3 % ou moins |
| Trafic mixte lecture-écriture | — | -2 % ou moins |
Le cas 7 (oltp_point_select spécial, 400 000 lignes) atteint un taux de réussite du cache de 99 % et présente la plus forte amélioration de QPS.
Cas de test et graphiques :
Cas 1 : 25 tables × 40 000 lignes, rand-type = special, oltp_read_only
Cas 2 : 25 tables × 40 000 lignes, rand-type = uniform, oltp_read_only
Cas 3 : 25 tables × 40 000 lignes, rand-type = special, oltp_point_select
Cas 4 : 25 tables × 40 000 lignes, rand-type = uniform, oltp_point_select
Cas 5 : 25 tables × 400 000 lignes, rand-type = special, oltp_read_only
Cas 6 : 25 tables × 400 000 lignes, rand-type = uniform, oltp_read_only
Cas 7 : 25 tables × 400 000 lignes, rand-type = special, oltp_point_select
Cas 8 : 25 tables × 400 000 lignes, rand-type = uniform, oltp_point_select
Cas 9 : 25 tables × 400 000 lignes, rand-type = special, oltp_read_write
Compatibilité
Le Fast Query Cache est compatible avec la fonctionnalité de cohérence globale (mode haute performance). Toutefois, si le Fast Query Cache et la cohérence globale (mode haute performance) sont actifs simultanément alors que l'optimisation MTT pour la cohérence globale (mode haute performance) est également activée, cette dernière devient inactive.
Pour plus d'informations sur la cohérence globale (mode haute performance), consultez Vue d'ensemble.