Partager la requête de cache MySQL et effacer l'exemple de code de commande

Cet article présente principalement l'utilisation détaillée des commandes de requête et d'effacement du cache MySQL. Pour certaines tables qui ne modifient pas fréquemment les données et qui ont un grand nombre de mêmes requêtes SQL, le cache de requêtes sera plus utile. peut s'y référer

Cache de requêtes Mysql
Le rôle du cache de requêtes est que lorsque la requête reçoit une requête qui est la même qu'avant, le serveur récupérera les résultats de le cache de requêtes au lieu d'analyser et d'exécuter à nouveau la dernière requête. Cela améliore considérablement les performances et fait gagner du temps.
1. Configurez le cache de requêtes
Modifiez le fichier de configuration, modifiez query_cache_size et query_cache_type sous [mysqld] (ajoutez sinon). Parmi eux, query_cache_size indique la taille du cache et query_cache_type a 3 valeurs, indiquant le type d'ensemble de résultats de sélection à mettre en cache. Les valeurs de query_cache_type sont les suivantes :
0 ou off désactive le cache 1 ou on active le cache, mais ne l'enregistre pas pour l'utiliser Instruction Select de sql_no_cache, sinon cache, sélectionnez le nom sql_no_cache à partir de wei où id=2
2 ou demandez l'activation de la mise en cache conditionnelle, uniquement l'instruction de sélection du cache avec sql_cache , cache sélectionnez le nom sql_cache depuis wei où id=4
exemple La configuration est la suivante Une fois la configuration terminée, redémarrez le serveur Mysql.

query_cache_size=10M 
query_cache_type=1

mysql> show variables like '%query_cache%'; 
+------------------------------+----------+ 
| Variable_name        | Value  | 
+------------------------------+----------+ 
| have_query_cache       | YES   | 
| query_cache_limit      | 1048576 | 
| query_cache_min_res_unit   | 4096   | 
| query_cache_size       | 10485760 | 
| query_cache_type       | ON    | 
| query_cache_wlock_invalidate | OFF   | 
+------------------------------+----------+ 
6 rows in set (0.00 sec)

Nous l'exécutons d'abord, sélectionnons count(*) depuis wei, puis exécutons-le à nouveau, vous pouvez voir ; que la seconde Le temps pris cette fois est bien inférieur à celui de la première exécution, car le résultat de la sélection est lu dans le cache une deuxième fois.

mysql> select count(*) from wei ; 
+----------+ 
| count(*) | 
+----------+ 
| 4194304 | 
+----------+ 
1 row in set (3.92 sec) 
mysql> select count(*) from wei ; 
+----------+ 
| count(*) | 
+----------+ 
| 4194304 | 
+----------+ 
1 row in set (0.00 sec)

mysql> show status like 'qcache%'; 
+-------------------------+----------+ 
| Variable_name      | Value  | 
+-------------------------+----------+ 
| Qcache_free_blocks   | 1    | 
| Qcache_free_memory   | 10475424 | 
| Qcache_hits       | 1    | 
| Qcache_inserts     | 1    | 
| Qcache_lowmem_prunes  | 0    | 
| Qcache_not_cached    | 0    | 
| Qcache_queries_in_cache | 1    | 
| Qcache_total_blocks   | 4    | 
+-------------------------+----------+ 
8 rows in set (0.00 sec)

• Qcache_free_blocks : Le nombre de blocs mémoire adjacents dans le cache. Un nombre élevé indique qu'il peut y avoir des fragments. FLUSH QUERY CACHE défragmentera le cache pour obtenir un bloc gratuit.

• Qcache_free_memory : Mémoire libre dans le cache.

• Qcache_hits : augmenté à chaque fois qu'une requête arrive dans le cache

• Qcache_inserts : augmenté à chaque fois qu'une requête est insérée. Le nombre de hits divisé par le nombre d'insertions est le taux d'échec.

• Qcache_lowmem_prunes : Le nombre de fois où le cache a manqué de mémoire et a dû être purgé pour faire de la place pour davantage de requêtes. Ce nombre est mieux visualisé sur une longue période ; s’il augmente, cela peut indiquer une fragmentation grave ou une mémoire insuffisante. (Les free_blocks et free_memory ci-dessus peuvent vous indiquer de quelle situation il s'agit)

• Qcache_not_cached : le nombre de requêtes qui ne conviennent pas à la mise en cache, généralement parce que ces requêtes ne sont pas des instructions SELECT ou ne sont pas utilisées maintenant ( ) et d’autres fonctions.

• Qcache_queries_in_cache : Le nombre de requêtes (et de réponses) actuellement mises en cache.

• Qcache_total_blocks : Nombre de blocs dans le cache.

Vider le cache

Syntaxe FLUSH de mysql (vider le cache)

FLUSH flush_option [,flush_option]

flush_option peut être l'un des éléments suivants :

• HOSTS C'est le plus utilisé et le plus souvent rencontré. Principalement utilisé pour vider la table du cache de l'hôte. Si certains de vos hôtes changent de numéro IP ou si vous recevez le message d'erreur Host... isblocked, vous devez effacer la table des hôtes. Lorsque plus d'erreurs max_connect_errors se produisent en continu pour un hôte donné lors de la connexion au serveur MySQL, MySQL bloquera les autres demandes de connexion de l'hôte pour des raisons de sécurité. Effacer la table des hôtes permet à l'hôte de tenter à nouveau de se connecter.

• LOGS Fermez le fichier journal binaire actuel et créez un nouveau fichier. Le nom du nouveau fichier journal binaire est ajouté au numéro du fichier binaire actuel par 1.

• PRIVILÈGES Ceci est également fréquemment utilisé à chaque fois après la ré-autorisation, afin que les nouvelles autorisations prennent effet immédiatement au cas où, le but est généralement d'obtenir. la table d'autorisation de la base de données. Rechargez les autorisations dans le cache.

• TABLES Fermez toutes les tables ouvertes et cette opération effacera le contenu du cache de requêtes.

• FLUSH TABLES AVEC READ LOCK Ferme toutes les tables ouvertes et ajoute un verrou en lecture à toutes les tables de la base de données jusqu'à ce que le déverrouillage des tables soit explicitement exécuté. Cette opération est souvent utilisée pour la sauvegarde des données.

• STATUT Réinitialise la plupart des variables d'état à 0.

• MASTER Supprimez tous les fichiers journaux binaires dans le fichier d'index du journal binaire, réinitialisez le fichier d'index du fichier journal binaire à vide et créez un nouveau fichier journal binaire. Cependant, ce n'est pas le cas. Utilisation plus recommandée, modifiée pour réinitialiser le maître. Comme vous pouvez l'imaginer, j'étais très naïf dans le passé. Cela pouvait être fait avec une simple commande, mais cela prenait plusieurs commandes. La méthode précédente consistait d'abord à trouver le nom du fichier journal binaire actuel, puis à utiliser la purge. opération.

• QUERY CACHE Réorganise le cache de requêtes, élimine les fragments et améliore les performances, mais n'affecte pas les données existantes dans le cache de requêtes. C'est la même chose que Flush table et Reset Query Cache (cela sera le cas). Effacera le contenu du cache de requêtes) sont différents.

• SLAVE C'est similaire à la réinitialisation de la réplication. Cela fait oublier à la base de données esclave l'emplacement de réplication de la base de données maître, et supprime également le journal de relais téléchargé. Comme le maître, ce n'est plus le cas. recommandé. Modifié sur Réinitialiser l'esclave. Ceci est également très utile.

De manière générale, les opérations de vidage seront enregistrées dans des fichiers journaux binaires, mais FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE et FLUSH TABLES WITH READ LOCK ne seront pas enregistrés, donc si ce qui précède les opérations sont enregistrées dans le fichier journal binaire, cela affectera la base de données esclave. Remarque : L'opération Reset joue en fait le rôle d'une version améliorée de l'opération Flush.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!