Skip navigation links
MySQL 5.0 Reference Manual :: 5 Administration du serveur :: 5.11 Cache de requêtes MySQL :: 5.11.1 Comment fonctionne le cache de requêtes
5.11.2 Options relatives au cache de requêtes dans un SELECT »
Section Navigation      [Toggle]

5.11.1. Comment fonctionne le cache de requêtes

Cette section décrit le fonctionnement du cache de requêtes lorsque ce dernier est opérationnel. La section Section 5.11.3, « Configuration du cache de requêtes » décrit comment contrôler ce cache, qu'il soit opérationnel ou pas.

Les requêtes sont comparées avant analyse, alors les deux requêtes suivantes seront considérées comme différentes pour le cache de requête : 

SELECT * FROM tbl_name
Select * from tbl_name

Les requêtes doivent être les mêmes (caractère à caractère) pour être considérées comme identiques. Les requêtes qui utilisent différentes bases de données, différents protocoles ou différents jeux de caractères sont alors considérées comme différentes, et mises en cache différemment.

Si un résultat de requête a été retourné depuis le cache de requête, alors la variable Com_select ne sera pas incrémenté, mais Qcache_hits le sera. See Section 5.11.4, « Statut du cache de requêtes et maintenance ».

Si une table change (INSERT, UPDATE, DELETE, TRUNCATE, ALTER ou DROP TABLE|DATABASE), alors toutes les requêtes mises en cache qui utilisaient cette table deviennent obsolètes et en sont retirées.

Les tables transactionnelles InnoDB qui ont été modifiées seront rendues obsolètes lorsqu'un COMMIT sera exécuté.

En MySQL 4.0, le cache de requêtes est désactivé dans les transactions : elles ne retourne pas le résultats. Depuis MySQL 4.1.1, le cache de requête fonctionne aussi dans les transactions avec les tables InnoDB : le serveur utilise le numéro de version de table pour détecter si le contenu est à jour ou non.

Avant MySQL 5.0, une requête qui commence avec un commentaire peut être mise en cache, mais ne sera jamais lue depuis le cache. Ce problème est résolu en MySQL 5.0.

Le cache de requête fonctionne pour les requêtes SELECT SQL_CALC_FOUND_ROWS ... et SELECT FOUND_ROWS(). Les requêtes FOUND_ROWS() retournent la valeur correcte même si la requête précédent a aussi été lue dans le cache, car le nombre de lignes lues est conservé dans le cache.

Une requête ne peut être mise en cache si elle contient l'une des fonctions suivantes :

BENCHMARK() CONNECTION_ID() CURDATE()
CURRENT_DATE() CURRENT_TIME() CURRENT_TIMESTAMP()
CURTIME() DATABASE() ENCRYPT() avec un paramètre
FOUND_ROWS() GET_LOCK() LAST_INSERT_ID()
LOAD_FILE() MASTER_POS_WAIT() NOW()
RAND() RELEASE_LOCK() SYSDATE()
UNIX_TIMESTAMP() sans paramètre USER()  

Une requête ne sera pas mise en cache dans ces conditions :

  • Elle contient des fonctions définies par l'utilisateur : UDF.

  • Elle contient des variables utilisateur.

  • Elle fait référence à des tables de la base mysql.

  • Elle est de l'une des formes suivantes : 

    SELECT ... IN SHARE MODE
SELECT ... INTO OUTFILE ...
SELECT ... INTO DUMPFILE ...
SELECT * FROM ... WHERE autoincrement_col IS NULL

    La dernière forme n'est pas mise en cache, car elle est utilisée comme palliatfi pour ODBC, afin d'obtenir la dernière valeur insérée. See Section 25.1.14.1, « Comment obtenir la valeur d'une colonne AUTO_INCREMENT avec ODBC ».

  • Elle utilise une table TEMPORARY.

  • Elle n'utilise pas de tables.

  • L'utilisateur a un droit de niveau colonne pour l'une des tables impliquée.

  • Avant la lecture de la requête dans le cache de requête, MySQL vérifie que l'utilisateur a les droits SELECT pour toutes les bases de données impliquées. Si ce n'est pas le cas, le résultat n'est pas utilisé.

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.