Je viens de lire l’article, mais j’aimerais préciser sur un sujet qui semble mal compris ou confus dans cet article.
Le cache MySQL et le Cache APC sont deux types de cache différents.
Le premier est un cache sur les requetes SQL et ne concerne que les processus de mise en mémoire des requetes à la base MySQL, d’ailleurs toutes les requetes bne sont pas cacheable, cela dépende des settings réalisés.
Le second APC est un cache dit “OpCode” et ne concerne aucunement les requetes MySQL mais le code php.
Un cache OpCode comme APC compile les requetes php en opcode: L’opcode est en fait une sorte d’intermédiaire entre le script et l’exécutable. Il n’y a nullement besoin d’avoir des requetes sql par php pour bénéficier du cache APC, en illustrant : il est tout a fait possible d’avoir un grand beneficie d’APC dans un application sans DB.
Ceux sont deux notions diférentes entre cache DB MySQL et cache OpCode. Su r les sites optimisés correctement , les deux types de cache sont utilisés simultanément.
Bon courage
Gilles

Premièrement merci de spécifier que la grosseur de la cache est 0 par défaut. Il est vrai que la cache est activée par défaut, mais avec une grosseur de 0 ce qui la rend inutilisable. Je vais corriger l’article.

Je me permets par contre de préciser quelques points. Il est vrai qu’il n’est pas commun de modifier des valeurs directement dans la DB, mais ce sont des choses qui arrivent, même dans un environnement de production. Il faut aussi se remettre en contexte: il s’agit d’implémenter une cache sur un simple Site Web – pas sur une application. Si le menu du site se trouve dans une table, il a fort à parier qu’il devra être modifié directement dans la base de données pour être mis à jour. Je ne juge pas ici la pertinence de mettre ce type de données dans une base.

Je comprends que la cache de requête n’est pas une solution magique. Oui, le type de requête influence son comportement. Comme tu as expliqué, on peut facilement invalider une grosse partie de la cache et l’exercice de remettre en cache à bien sur un coût. L’invalidation elle-même a un coût non négligeable. Mais je reviens encore au contexte. Pour un Site Web possédant un CMS, la majorité des requêtes se font en lecture. C’est un cas typique où la cache de MySQL brille. Le gain est quasi assuré.

Il n’était pas question dans mon article d’optimisation très haut niveau, ce que tu sembles reprocher à ma réponse. Bien sur, je vais préférer memcached à la query cache de MySQL pour plusieurs raisons afin d’avoir une performance accrue. C’était un article qui se voulait une introduction aux deux différents types de cache.

1- Tu peux ajouter SQL_NO_CACHE dans tes requêtes. Ce mot-clé permet de ne pas utiliser la cache même si elle est activée”

2- Tu peux simplement modifier la requêtes. Pour retourner une résultat en cache, il faut que la requete utilisée soit très exactement la même. Donc, le simple fait d’ajouter un whitespace de plus, ou formuler différement la même requête suffit pour ne pas utiliser celle du cache. Attention parcontre, chaque modification à “la même” est concidérée comme une nouvelle requête au point de la vue de la cache.

3- Tu peux arreter la cache avec SET query_cache_type = 0; pour la désactiver et SET query_cache_type = 1; pour la ré-activer.

Olivier DASINI