I – Qu’est ce que le query cache

Le query cache de MySQL a été introduit à partir de la version 4.0 de MySQL. Son principe de fonctionnement est simple : c’est une table de hash géante qui associe des requêtes SQL brutes à un ensemble de résultats.

Cela signifie que si vous rajoutez un espace ou changer une majuscule à votre requête SQL, elle sera différente du point de vue du query cache.

Cette approche simple signifie aussi qu’à la moindre modification / écriture dans une table, il faut que toutes les entrées du query cache concernant la table en question soient invalidées.

Dans des applications qui utilisent de la lecture de façon intensive, sans beaucoup d’écriture, …

Selon le livre «Audit & optimisation, MySQL 5 - éditions Eyrolles», le cache de requêtes ou query cache est un système de cache mémoire interne à MySQL, transparent pour l'application, qui ne stocke que les requêtes SELECT et leurs résultats.

L'apport de ce cache est particulièrement dépendant de votre application. Il est coutume de dire qu'il est (très) pénalisant dans des environnements où les requêtes d'écritures sont nombreuses, notamment à cause de son mécanisme d'invalidation (et de problèmes de contentions de façon générale).

A l'opposé, il peut être intéressant de l'activer, dans des environnements à forte charges de lectures, si les mêmes requêtes reviennent très fréquemment, plus particulièrement lors de l'utilisation de tables MyISAM.

Cependant, un environnement à forte charge en lecture n'est pas une condition suffisante pour s'assurer de bonne performances avec le query …

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 …

La query cache de MySQL joue un rôle important dans la performance de plusieurs sites Web.  Elle a pour avantage d’être  transparente, c’est-à-dire que la ou les applications qui s’en servent n’ont pas besoin d’être modifiées.

J’ai recu la semaine passée la question suivante (je résume):

Je souhaite utiliser une cache pour le menu de mon site afin de le rendre plus performant. Puisque le contenu du menu ne change pratiquement jamais, est-il plus avantageux d’utiliser APC Cache que la Query Cache de MySQL puisque la communication s’effectue selon un schéma comme:

php -> cache_apc (ram)
php -> mysql -> query_cache (ram)

Je souhaite réduire au minimum les requêtes SQL exécutées.

Personnellement, j’utiliserais la cache de MySQL. Tout d’abord, il faut savoir qu’il y a une énorme différence entre les 2 caches.

MySQL Query Cache est …

Il y a plusieurs moyens d’évaluer l’efficacité de la Query Cache. On peut se satisfaire de connaitre le nombre de hit à la cache versus le nombre de SELECT. La commande SHOW STATUS nous donne tout ce qu’on a besoin de savoir: Qcache_hits/(Com_select+Qcache_hits) ( notez que nous devons additionner Com_Select et Qcache_Hits car Com_Select n’est pas incrémenté lorsque le résultat est retourné par la cache).

Il y a certaines questions à se demander si vous obtenez un bas pourcentage. Quel genre de requêtes sont stockées en cache ? Est-ce que la cache crée une charge supplémentaire qui en vaut la peine ? On ne peut malheureusement pas savoir quelles requêtes sont dans la cache, mais on peut connaitre une partie de la surchage créé en calculant le taux d’invalidation des requêtes: (Com_insert+Com_delete+Com_update+Com_replace)/Qcache_hits

La variable Qcache_lowmem_prunes indique le …