Maison  >  Article  >  base de données  >  Analyser la méthode et les paramètres de démarrage du cache MySQL (query_cache_size)

Analyser la méthode et les paramètres de démarrage du cache MySQL (query_cache_size)

怪我咯
怪我咯original
2017-04-01 09:59:321688parcourir

MySQL requête cache est fourni depuis la version 4.1, mais cela vaut la peine de l'étudier aujourd'hui. Dans la configuration par défaut, cette fonction de MySQL n'est pas activée. Vous constaterez peut-être que la valeur de sa variable have_query_cache est oui via des variables d'affichage comme '%query_cache%' ; Il est facile de penser que si ce paramètre est OUI, cela signifie que QueryCache est activé. En fait, ce paramètre indique si le. la version actuelle de MYSQL prend en charge le cache de requêtes. En fait, l'activation du cache de requêtes dépend de la valeur d'un autre paramètre : query_cache_size. La valeur est 0, ce qui signifie que le cache de requêtes est désactivé et que la configuration par défaut est 0.


Méthode de configuration :

Recherchez le contenu suivant dans le fichier de configuration my.ini ou my.cnf de MYSQL :

# Le cache de requête est utilisé pour mettre en cache les résultats SELECT et les renvoyer plus tard

# sans exécuter à nouveau la même requête. L'activation du cache de requête

# peut entraîner des améliorations significatives de la vitesse, si votre

# a beaucoup de requêtes identiques et change rarement de tables. Consultez la variable d'état

# « Qcache_lowmem_prunes » pour vérifier si la valeur actuelle

# est suffisamment élevée. pour votre chargement.

# Remarque : Dans le cas où vos tables changent très souvent ou si vos requêtes sont

# textuellement différentes à chaque fois, le cache des requêtes peut entraîner un

# ralentissement au lieu d'une amélioration des performances.
query_cache_size=0

Les informations ci-dessus sont la configuration par défaut, et son commentaire signifie que le cache de requêtes MYSQL est utilisé pour mettre en cache les résultats des requêtes de sélection. Et lorsque la même demande de requête sera reçue la prochaine fois, le traitement réel de la requête ne sera plus effectué et les résultats seront renvoyés directement. Un tel cache de requête peut augmenter la vitesse de la requête et optimiser les performances de la requête. avoir un grand nombre de requêtes identiques ou similaires. La requête modifie rarement les données du tableau, sinon il n'est pas nécessaire d'utiliser cette fonction. Vous pouvez vérifier si la valeur actuelle correspond à la charge actuelle de votre système via la valeur de la variable Qcache_lowmem_prunes. Remarque : Si la table que vous interrogez est mise à jour fréquemment et contient rarement la même requête, il est préférable de ne pas utiliser le cache de requêtes.

Méthode de configuration spécifique :

1. Définissez query_cache_size sur une taille spécifique. La taille spécifique dépend de la situation réelle de la requête, mais il est préférable de la définir sur un multiple de 1024, avec une valeur de référence de 32 M.

2. Ajoutez une ligne : query_cache_type=1

Le paramètre query_cache_type est utilisé pour contrôler le type de cache. Notez que cette valeur ne peut pas être définie avec désinvolture et doit être définie sur un nombre. Les éléments et descriptions facultatifs sont les suivants :
Analyser la méthode et les paramètres de démarrage du cache MySQL (query_cache_size)

S'il est défini sur 0, alors on peut dire que votre cache est inutile du tout, ce qui équivaut à être désactivé. Mais dans ce cas, le système doit-il allouer la taille définie par query_cache_size ? Cette question doit-elle être testée ?

Si défini sur 1, tous les résultats seront mis en cache, sauf si votre instruction select utilise SQL_NO_CACHE pour désactiver la mise en cache des requêtes.

Si défini sur 2, seules les requêtes qui doivent être mises en cache via SQL_CACHE dans l'instruction select seront mises en cache.

OK, certains des fichiers après configuration sont les suivants :

query_cache_size=128M

query_cache_type=1
Enregistrez le fichier, redémarrez le service MYSQL, puis requête via ce qui suit Vérifiez s'il est vraiment activé :

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             | 134217728 |

| query_cache_type             | ON        |

| query_cache_wlock_invalidate | OFF       |

+——————————+———–+

6 rows in set (0.00 sec)


Cela dépend principalement de la cohérence des valeurs de query_cache_size et query_cache_type avec ce que nous avons défini :

La valeur de query_cache_size ici est 134217728 , nous définissons 128M, ce qui est en fait la même, mais les unités sont différentes. Vous pouvez la convertir vous-même : 134217728 = 128*1024*1024.

query_cache_type est défini sur 1 et affiché comme ON. Cela a déjà été mentionné.

En bref, voir l'affichage ci-dessus signifie que les paramètres sont corrects, mais que la requête puisse être mise en cache dans la requête réelle doit encore être testée manuellement. Nous pouvons la tester via l'état d'affichage comme '%Qcache. %'; Maintenant que nous avons activé la fonction de cache de requête, avant d'exécuter la requête, nous examinons d'abord les valeurs des paramètres pertinents :

mysql> show status like ‘%Qcache%';

+————————-+———–+

| Variable_name           | Value     |

+————————-+———–+

| Qcache_free_blocks      | 1         |

| Qcache_free_memory      | 134208800 |

| Qcache_hits             | 0         |

| Qcache_inserts          | 0         |

| Qcache_lowmem_prunes    | 0         |

| Qcache_not_cached       | 2         |

| Qcache_queries_in_cache | 0         |

| Qcache_total_blocks     | 1         |

+————————-+———–+

8 rows in set (0.00 sec)


这里顺便解释下这个几个参数的作用:

Qcache_free_blocks:表示查询缓存中目前还有多少剩余的blocks,如果该值显示较大,则说明查询缓存中的内存碎片过多了,可能在一定的时间进行整理。

Qcache_free_memory:查询缓存的内存大小,通过这个参数可以很清晰的知道当前系统的查询内存是否够用,是多了,还是不够用,DBA可以根据实际情况做出调整。

Qcache_hits:表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大,缓存效果越理想。

Qcache_inserts: 表示多少次未命中然后插入,意思是新来的SQL请求在缓存中未找到,不得不执行查询处理,执行查询处理后把结果insert到查询缓存中。这样的情况的次数,次数越多,表示查询缓存应用到的比较少,效果也就不理想。当然系统刚启动后,查询缓存是空的,这很正常。

Qcache_lowmem_prunes:该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值,用户可以适当的调整缓存大小。

Qcache_not_cached: 表示因为query_cache_type的设置而没有被缓存的查询数量。

Qcache_queries_in_cache:当前缓存中缓存的查询数量。

Qcache_total_blocks:当前缓存的block数量。
下边我们测试下:

比如执行如下查询语句

mysql> select * from user where id = 2;

+—-+——-+

| id | name  |

+—-+——-+

|  2 | test2 |

+—-+——-+

1 row in set (0.02 sec)


然后执行show status like ‘%Qcache%',看看有什么变化:

mysql> show status like ‘%Qcache%';

+————————-+———–+

| Variable_name           | Value     |

+————————-+———–+

| Qcache_free_blocks      | 1         |

| Qcache_free_memory      | 134207264 |

| Qcache_hits             | 0         |

| Qcache_inserts          | 1         |

| Qcache_lowmem_prunes    | 0         |

| Qcache_not_cached       | 3         |

| Qcache_queries_in_cache | 1         |

| Qcache_total_blocks     | 4         |

+————————-+———–+

8 rows in set (0.00 sec)


对比前面的参数值,我们发现Qcache_inserts变化了。Qcache_hits没有变,下边我们在执行同样的查询

select * from user where id = 2,按照前面的理论分析:Qcache_hits应该等于1,而Qcache_inserts应该值不变(其他参数的值变化暂时不关注,读者可以自行测试),再次执行:
show status like ‘%Qcache%',看看有什么变化:

mysql> show status like ‘%Qcache%';

+————————-+———–+

| Variable_name           | Value     |

+————————-+———–+

| Qcache_free_blocks      | 1         |

| Qcache_free_memory      | 134207264 |

| Qcache_hits             | 1         |

| Qcache_inserts          | 1         |

| Qcache_lowmem_prunes    | 0         |

| Qcache_not_cached       | 4         |

| Qcache_queries_in_cache | 1         |

| Qcache_total_blocks     | 4         |

+————————-+———–+

8 rows in set (0.00 sec)


OK,果然跟我们分析的完全一致。



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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn