Analyse d'un exemple de requête de journal lent MySQL

1. Concept de journal de requêtes lent

Utiliser expliquer pour analyser les instructions SQL consiste à optimiser les problèmes SQL et d'index. Pour un véritable projet d'entreprise, les instructions SQL peuvent atteindre des dizaines de milliers, nous ne pouvons donc pas les expliquer et les analyser une par une. Où pouvons-nous obtenir ces SQL longs et gourmands en performances ? ?

Nous pouvons ouvrir journal de requête lent :

pour estimer une limite de temps (20 ms, 100 ms) en fonction de l'activité spécifique et de la concurrence, après configuration, démarrez l'entreprise, ouvrez le journal des requêtes lentes après le test de stress, vous verrez le SQL qui dépasse le temps d'exécution, puis utilisez expliquer pour analyser ces instructions SQL chronophages

Les étapes sont les suivants :

# 🎜🎜#

• Activez le commutateur de journal des requêtes lentes slow_query_log

slow_query_log

• 设置合理的、业务可以接受的慢查询时间上限

• 压测执行各种业务

• 查看慢查询日志，找出所有执行耗时的SQL语句

• 用explain分析这些耗时的SQL语句，从而针对性优化

MySQL可以设置慢查询日志，当SQL执行的时间超过我们设定的时间，那么这些SQL就会被记录在慢查询日志当中，然后我们通过查看日志，用explain分析这些SQL的执行计划，来判定为什么效率低下，是没有使用到索引？还是索引本身创建的有问题？或者是索引使用到了，但是由于表的数据量太大，花费的时间就是很长，那么此时我们可以把表分成多个小表等。

慢查询日志相关的参数如下所示：
（MySQL定义的很多的全局的开关，都是在全局变量中存储，可以用show/set variables查看或者设置全局变量的值）

慢查询日志开关默认是关闭的
慢查询日志的路径：默认在/var/lib/mysql/下

慢查询日志记录了包含所有执行时间超过参数 long_query_time（单位：秒）所设置值的 SQL语句的日志，在MySQL上用命令可以查看，如下：

这个值是可以修改的：

二、慢查询日志实践

1. 打开慢查询日志开关slow_query_log

在打开慢查询日志开关的时候，报错表示slow_query_log是一个global的变量（也有只影响当前session的变量，如：long_query_time 、profiling），修改后会影响所有的session，即影响所有正在访问当前MySQL server的客户端。

打开慢查询日志开关成功！

2. 设置合理的、业务可以接受的慢查询时间上限long_query_time

查看另一个session

发现还是默认的10s，故long_query_time只影响当前session

3. 压测执行各种业务

已经超过我们设置的long_query_time=0.1s

4. 查看慢查询日志

路径：/var/lib/mysql/#🎜🎜 #Définir un délai de requête lent raisonnable et acceptable pour l'entreprise

Stress test pour exécuter divers services

Consultez le journal des requêtes lentes et découvrez toute la consommation d'exécution Instructions SQL chronophages

Utilisez expliquer pour analyser ces instructions SQL chronophages afin d'optimiser en conséquence

MySQL peut configurer des journaux de requêtes lentes Lorsque le temps d'exécution SQL dépasse le temps que nous avons défini, ces SQL seront enregistrés dans les journaux de requêtes lentes. Nous pouvons ensuite déterminer pourquoi en affichant les journaux. et utiliser expliquer pour analyser les plans d'exécution de ces SQL Inefficacité, est-ce parce que l'index n'est pas utilisé ? Ou y a-t-il un problème avec la création de l'index lui-même ? Ou l'index est utilisé, mais comme la quantité de données dans la table est trop grande, cela prend beaucoup de temps. À ce stade, nous pouvons diviser la table en plusieurs petites tables, etc.

Les paramètres liés au journal des requêtes lentes sont les suivants :

(De nombreux commutateurs globaux définis par MySQL sont stockés dans des variables globales. Vous pouvez utiliser show/set variablesAfficher ou définir la valeur des variables globales)

Le commutateur du journal des requêtes lentes est désactivé par défaut

Le chemin du journal des requêtes lentes : la valeur par défaut est sous /var/lib/mysql/# 🎜🎜#<br>Le journal des requêtes lentes enregistre les journaux contenant toutes les instructions SQL dont le temps d'exécution dépasse la valeur définie par le paramètre long_query_time (unité : secondes). Vous pouvez le visualiser avec la commande sur MySQL, comme suit. : <img src="https://img.php.cn/upload/article/000/465/014/168534280178713.jpg" alt="Analyse dun exemple de requête de journal lent MySQL">#🎜🎜 #<img src="https://img.php.cn/upload/article/000/465/014/168534279951094.jpg" alt="Analyse d'instance de requête de journal lent MySQL"> <br> Cette valeur est OK Modifié :

#🎜🎜##🎜🎜##🎜🎜#2. Pratique du journal de requête lent#🎜🎜##🎜🎜##🎜🎜#1. Activez le commutateur de journal de requête lent slow_query_log#🎜🎜## 🎜🎜##🎜🎜##🎜 🎜##🎜🎜#Ouverture lente Lors de l'interrogation du commutateur de journal, un message d'erreur indique que slow_query_log est une variable globale (il existe également des variables qui n'affectent que la session en cours, telles que : long_query_time, profilage Après modification, cela affectera). toutes les sessions, c'est-à-dire tous les clients qui accèdent au serveur MySQL actuel. #🎜🎜##🎜🎜## 🎜🎜#Activation réussie du commutateur de journal des requêtes lentes ! #🎜🎜##🎜🎜##🎜🎜#2. Définissez une limite supérieure de temps de requête lente raisonnable et acceptable pour l'entreprise long_query_time#🎜🎜##🎜🎜##🎜🎜##🎜🎜# Afficher une autre session#🎜🎜##🎜🎜##🎜🎜# Il a été constaté que la valeur par défaut est de 10 s, donc long_query_time n'affecte que la session en cours#🎜🎜##🎜🎜##🎜🎜#3 Tests de stress pour exécuter divers services#🎜🎜##🎜🎜##🎜🎜##🎜🎜# a dépassé le long_query_time=0,1s que nous avons défini#🎜🎜##🎜🎜 ##🎜🎜 #4. Vérifiez le journal des requêtes lentes#🎜🎜##🎜🎜##🎜🎜#Chemin : /var/lib/mysql/#🎜🎜##🎜🎜##🎜 🎜##🎜🎜 ##🎜🎜##🎜🎜##🎜🎜#5. Utilisez expliquer pour analyser ces instructions SQL chronophages afin de les optimiser en conséquence#🎜🎜##🎜🎜##🎜🎜##🎜🎜# #🎜🎜# Effectuez une recherche dans la table entière et parcourez l'intégralité de l'arborescence d'index de clé primaire. #🎜🎜##🎜🎜#Nous devons ajouter un index au mot de passe, puis nous rappeler que le mot de passe est au format chaîne, car si une conversion de type est impliquée, l'index ne peut pas être utilisé #🎜🎜##🎜🎜# 3. Afficher les profils pour voir le fonctionnement spécifique de SQL Time#🎜🎜##🎜🎜#MySQL n'affiche généralement l'heure qu'à deux décimales#🎜🎜##🎜🎜##🎜🎜# Activez le commutateur de profilage pour afficher une heure plus détaillée #🎜🎜#

Aucune erreur n'est signalée, indiquant que la variable de profilage n'affecte que la session en cours

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!