Le cache de requêtes de MySQL, ou query cache[1], est une fonctionnalité relativement basique permettant de conserver en mémoire le résultat des dernières interrogations effectuées afin de pouvoir resservir instantanément la réponse à une requête si la même interrogation a été faite récemment. Dans la majorité des configurations, il est très probable qu'une même requête revienne plusieurs fois, ce qui rend cette fonctionnalité très efficace. Il est bien sûr possible de totalement la désactiver pour quelques configurations qui n'y sont pas adaptées.

J'ai déjà eu l'occasion de voir un serveur MySQL tournant sur une configuration ridicule[2] absorber environ 4000 requêtes par seconde en utilisant uniquement le query cache.

Ce cache possède se heurte néanmoins à un sacré problème : la moindre modification sur une table entraîne la suppression pure et simple du cache de requête associé, et non une simple mise à jour de ce cache. Il est donc impératif de limiter le nombre d'écritures sur son serveur lorsque l'on souhaite maximiser l'utilisation du cache de requête en lecture, par exemple en dédiant un serveur aux écritures et en utilisant des réplicats pour les accès en lecture. Si on peut se permettre de différer les mises à jours, on peut ainsi garder un query cache très efficace tout en gardant de nombreux accès en écriture.

Il y a quelques mois, j'ai rencontré de nouvelles limitations assez énervante sur le même sujet. MySQL 5 a apporté à ma grande joie le support quasiment complet des prepared statements, des procédures stockées et des triggers, ouvrant la voie à de nombreuses manipulations intéressantes.
Malheureusement, l'implémentation du cache de requête est faite de telle manière que la présence ou non d'une requête dans ce cache n'est vérifiée qu'au moment du parsage de celle-ci. Or évidemment ce parsage est fait bien avant l'exécution dans le cas des prepared statements et des procédures stockées, c'est d'ailleurs ce qui en fait tout l'intérêt :) Donc, pas de cache dans ces deux cas. Cela signifie en clair qu'il faut bien réfléchir en fonction de son utilisation à la meilleure implémentation possible. A priori, cela donnerait :

Un ratio lectures / modifications important et des requêtes relativement simples et répétitives :

-> Query Cache activé, pas de prepared statements, pas de procédures stockées.

Pas mal d'écritures ou des requêtes avec une structure identique mais dont le contenu varie légérement, pas d'enchaînement de requêtes (SELECT puis selon le résultat je fais un update dans un cas, un insert dans l'autre par exemple) :

-> Prepared statements

La même chose que précédemment mais avec des enchaînements de requêtes, ou une logique plus complexe :

-> Procédures stockées

Dans tous les cas, rien ne vaut le test de charge :) Attention, je parle uniquement de la recherche de bonnes performances. Bien souvent il n'y a aucunement besoin de descendre à ce genre de réflexions, et il vaut mieux utiliser la solution qui nous semble la plus propre ou la plus adaptée.

[1] http://dev.mysql.com/doc/refman/5.0/en/query-cache.html
[2] inférieure à celle d'une dédibox ou d'un kimsufi par exemple