En tant que boulimique de MySQL, je me promène souvent sur la toile à la recherche d’informations, de bonnes et de moins bonnes…
Je suis tombé sur un article traitant du cache de requêtes de MySQL (MySQL Query Cache) sur le blogue de Patrick Lafontaine (http://www.noidea.ca/)
Je me permet de faire quelques commentaires ici.
En préambule, quelques informations nécessaires sur le cache de requêtes:
Système de cache interne à MySQL qui ne stocke que les requêtes SELECT et leur résultat ie pas d’INSERT, UPDATE, DELETE…
Les requêtes ( SELECT donc) doivent être strictement identiques ie même casse, mêmes espaces entre les mots,…
Ex 3 requêtes différentes pour le cache :
SELECT nom, prenom FROM client WHERE client_id=123;
select nom, prenom FROM client WHERE client_id=123; /* la casse du select*/
SELECT nom, prenom FROM client WHERE client_id=123; /*plusieurs espaces entre client et WHERE*/
Le cache est toujours à jour car en cas de modification d’une table, toutes les requêtes en relations avec cette table sont invalidées.
Le cache de requêtes est en général utile lorsque:
- Les modifications sur les tables ne sont pas très fréquentes
- Beaucoup de requêtes de lectures identiques
- Utilisation de tables MyISAM. Moins intéressant pour InnoDB
Pour rebondir sur l’article de Patrick Lafontaine
« puisqu’elle est activée par défaut. »
Le cache de requêtes n’est pas activé par défaut, car la variable query_cache_size vaut 0. Si vous voulez vous en servir, il faut lui donner une taille en octet. Mettez le tout dans votre fichier de configuration. Assurez vous également que la variable query_cache_type est différente de OFF
« c’est-à-dire que la ou les applications qui s’en servent n’ont pas besoin d’être modifiées »
Pour une optimisation optimale, il est parfois nécessaire de modifier les requêtes SELECT avec SQL_CACHE ou SQL_NO_CACHE. On choisit alors quelles requêtes seront mis en cache.
« Si quelqu’un modifie la valeur directement dans MySQL, la cache possèdera la vieille valeur jusqu’à ce qu’un processus l’invalide. »
Sur une machine de production, ce type de manipulation reste quand même exceptionnel, sinon c’est qu’il y a des choses à revoir dans les process.
« Puisque les données ne changent pratiquement jamais, je ne me casserais pas la tête à réinventer la roue. MySQL fait déjà pour vous ce que APC ferait, sans le moindre effort. »
Si le contenu ne change JAMAIS, il n’a à priori rien à faire en base ! Il vaut mieux utiliser un menu statique et laisser la base faire son boulot avec du contenu dynamique. Dans le même ordre d’idée, plus le cache est éloigné du disque plus il est performant. En d’autres termes, le goulet d’étranglement est souvent (parfois) la base de données, de plus elle est souvent (parfois) plus difficilement scalable que le reste. L’utilisation d’un cache applicatif est rarement une mauvaise idée (il suffit de connaître l’identité du plus gros consommateur de memcached au monde http://www.facebook.com/note.php?note_id=39391378919)
« Il est donc plus avantageux de cacher les processus lourds que les légers. »
Malheureusement, avec le cache de requêtes ce n’est pas aussi simple. Admettons qu’une requête renvoyant un gros résultat prenne plus de temps qu’une renvoyant un plus petit. Si cette grosse requête vire toutes les autres requêtes du cache, l’apport du cache pour les autres requêtes est perdu, elle devront être misent à nouveau dans le cache ca qui implique des recherches inutiles dans le caches et de nouveaux accès disque…
« Lorsque la Query Cache de MySQL est activée, le processus de cacher les résultats et de les invalider s’effectue tout seul de manière invisible. Ainsi, d’autres requêtes que vous ne soupçonnez même pas bénéficient de la cache »
L’efficacité du cache de requêtes est vraiment lié à l’application. Il dépend du type de requêtes SELECT, de leur fréquence et de la fréquence des écritures dans les tables. Le gain n’est pas évident et est loin d’être immédiat, car pour chaque requête « cachable » MySQL devra l’analyser, devra la hacher, devra vérifier s’il elle est dans le cache ou non. Et ceci à un coût…
Vous pouvez calculer le taux d’efficacité du cache de requêtes avec la formule suivant:
Qcache_hits / (Qcache_hits + Com_select )
Pour finir, quelques paramètres et commandes
Paramètres principaux:
query_cache_size: Doit être différent de zéro pour activer le cache
query_cache_type:
Commandes principales:
FLUSH QUERY CACHE
Vider le cache de requêtes:
-
RESET QUERY CACHE
-
FLUSH TABLES
-
Redémarrer le serveur
Variables d’état: SHOW STATUS LIKE ‘Qcache%’ ;
Qcache_free_blocks : nombre de blocs libres
Qcache_free_memory : mémoire libre
Qcache_hits : nombre de fois qu’il a servi
Qcache_inserts : nombre de requêtes insérées
Qcache_lowmem_prunes : nombre de requêtes supprimées car plus de place
Qcache_not_cached : nombre de requêtes non « cachables »
Qcache_queries_in_cache : nombre de requêtes dans le cache
Qcache_total_blocks : nombre de blocs de mémoire
Tags: query cache
, Deplus APC , memcache ne souffre pas de la concurrence car il n’ont pas l’obligation d’etre exacte, car il peuvent toujours sortir la version anterieur pendant que la nouvelle version est ecrite , donc pas de MUTEX. Un autre atout et que le cache PHP local fait economiser le cout du reseau et la copie memoire inter process sous reserve de ne pas utiliser un wrapper lib client , enfin le cout de l’authentification MySQL est aussi supprimer , soit 3ms et plus si pas de skip-name-resolv, mais ca c’est pour un autre de tes billets 
[...] Olivier Dasini : MySQL Query cache () [...]
[...] Olivier Dasini : MySQL Query cache (0 visite) [...]
[...] This post was Twitted by HerveThouzard [...]
[...] http://dasini.net/blog/2009/10/12/mysql-query-cache/ (lu rapidement, mais le cache de requête est visiblement fait par défaut sur une conf mysql récente) [...]