Comment fonctionne le cache de requêtes

Comment fonctionne le cache de requêtes

Options relatives au cache de requêtes dans un SELECT
>>>

5.10 Cache de requêtes MySQL
5 Administration du serveur
Manuel de Référence MySQL 4.1 : Version Française

->Comment fonctionne le cache de requêtes
. Options relatives au cache de requêtes dans un SELECT
. Configuration du cache de requêtes
. Statut du cache de requêtes et maintenance

5.10.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 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. Status et maintenance du cache de requêtes .

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. 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é.

<<	Comment fonctionne le cache de requêtes	>>
Administration du serveur	Cache de requêtes MySQL	Options relatives au cache de requêtes dans un SELECT