Méthode : 1. Si la requête lente n'est pas activée, utilisez "set global slow_query_log='ON';" pour activer la requête lente ; 2. Utilisez "set global slow_query_log_file=path" pour définir l'emplacement de stockage du fichier de requête lente ; Utilisez "chemin subl". Interrogez simplement le fichier.
L'environnement d'exploitation de ce tutoriel : système centos 7, version mysql8.0.22, ordinateur Dell G3.
Enregistrer la recherche d'instructions SQL lentes dans Mysql
Le journal des requêtes lentes slow_query_log est utilisé pour enregistrer les instructions SQL lentes. Utilisez le journal des requêtes pour trouver quelle instruction SQL est la plus lente. SQL peut être optimisé.
Connectez-vous à la base de données mysql :
1. Vérifiez si la requête lente actuelle est activée. Si elle n'est pas activée, activez-la
et l'heure spécifiée par la requête lente :
.show variables like 'slow_query_log'; show variableslike 'long_query_time';
Si après votre requête, si le résultat est OFF, vous devez le changer sur ON via les paramètres pertinents :
set global slow_query_log='ON';
Réglez le temps de suivi lent des requêtes sur 1 s :
Après avoir défini ce paramètre , le monde n'est pas Il deviendra 1 immédiatement et prendra effet après le redémarrage de la base de données :
2 Définissez l'emplacement où le fichier journal des requêtes lentes est enregistré :
set global slow_query_log_file='/var/lib/mysql/test_1116.log';
3. fichiers configurés :
sudo subl /var/lib/mysql/test_1116.log
Développer les connaissances :
Comment résoudre les problèmes de requêtes lentes dans la base de données MySQL
J'ai récemment rencontré plusieurs fois le problème de la réponse lente de la base de données. J'ai réglé le flux de traitement et l'analyse. idées et exécuté le scénario. J'espère que cela aide les autres.
Performances des requêtes MySQL lentes
Il est évident que la plupart des fonctions de l'application sont ralenties, mais elles ne sont pas complètement inutilisables. Il y a toujours une réponse après une longue attente. Mais l’ensemble du système semble très bloqué.
Requête du nombre de requêtes lentes
De manière générale, pour un serveur MySQL fonctionnant normalement, il est normal que le nombre de requêtes lentes par minute soit à un chiffre. Parfois, il peut atteindre deux chiffres s'il est proche. à 100, le système peut avoir des problèmes, mais il peut encore être utilisé à peine. Le nombre de requêtes lentes qui ont mal tourné ces quelques fois a atteint plus de 1 000.
Le nombre de requêtes lentes est stocké dans la table slow_log de la bibliothèque mysql.
SELECT * FROM `slow_log` where start_time > '2019/05/19 00:00:00';
De cette façon, vous pourrez connaître les requêtes lentes de la journée.
Vérifiez l'état de la requête en cours
Tout le monde devrait généralement utiliser show processlist pour vérifier les requêtes en cours d'exécution dans le système. En fait, ces données sont également stockées dans la table processlist de la bibliothèque information_schema, donc si vous le souhaitez. faites une requête conditionnelle, interrogez-la directement. Il est plus pratique de créer un tableau.
Par exemple, affichez tous les processus en cours
select * from information_schema.processlist
Affichez les requêtes en cours et triez-les dans l'ordre inverse en fonction du temps d'exécution
select * from information_schema.processlist where info is not null order by time desc
Une base de données fonctionnant normalement, car une requête s'exécute très rapidement et les informations capturées par notre sélection n'est pas Le nombre de requêtes nulles sera très faible. Une bibliothèque très chargée comme la nôtre ne peut généralement trouver que quelques éléments. Si des dizaines de requêtes contenant des informations non vides peuvent être trouvées en même temps, on peut également considérer qu'il y a un problème avec le système.
Problèmes du système et positionnement
Après avoir remarqué que le système ralentissait, nous avons immédiatement vérifié en utilisant des requêtes lentes et en vérifiant la liste de processus. Nous avons constaté que le nombre de requêtes lentes par minute s'élevait à plus de 1 000, et un grand nombre de. les requêtes ont été accumulées au cours de l'exécution.
Étant donné que la priorité absolue est de restaurer le fonctionnement normal du système dès que possible, le moyen le plus direct d'y remédier est de vérifier combien de résultats de requête dans la liste de processus sont à l'état verrouillé ou ont été exécutés pendant longtemps et tuez ces processus avec la commande kill . En supprimant continuellement ces processus susceptibles de provoquer une congestion du système, le système peut éventuellement être temporairement restauré à son état normal. Bien entendu, il ne s'agit que d'une mesure provisoire.
De plus, le plus important est bien sûr d'analyser quelles requêtes provoquent une congestion du système. Nous utilisons toujours des requêtes lentes pour l'analyse.
Il existe plusieurs indicateurs importants dans les résultats des requêtes lentes de la table de requête :
heure de début start_time Ce paramètre doit être utilisé pour correspondre à l'heure du problème du système afin de localiser quelle requête est le coupable.
query_time temps de requête
rows_sent et rows_examined sont le nombre de résultats envoyés et le nombre de lignes analysées par la requête. Ces deux valeurs sont particulièrement importantes, notamment rows_examined. Fondamentalement, cela nous indique quelle requête est la « grande » requête à laquelle prêter attention.
En fonctionnement réel, nous analysons également les requêtes avec un grand nombre de lignes_examinées une par une, ajoutons des index et modifions l'écriture des instructions de requête pour résoudre complètement le problème.
Résultats du traitement et réflexion
Après avoir vérifié et rectifié toutes les requêtes lentes, le nombre actuel de requêtes lentes MySQL par minute oscille entre 1 et 2, et la charge du processeur est également très faible. Le problème est fondamentalement résolu.
Réfléchissez aux raisons du problème, il y a quelques points auxquels il faut prêter attention :
1. Les problèmes de base de données ne posent souvent pas de problèmes lorsqu'ils sont en ligne, mais il existe un processus d'accumulation continue de mauvaises instructions de requête. va progressivement augmenter la charge du système. , la goutte d'eau qui fait déborder le vase semble souvent inexplicable
2 La goutte d'eau qui fait déborder le vase peut même ne pas exister du tout, mais à mesure que l'utilisation des utilisateurs augmente. , la quantité de données augmente. Accumulation et épidémie
3 Puisque l'émergence de problèmes est un processus cumulatif, il est nécessaire de revoir chaque code avant de le publier
4. la surveillance des requêtes lentes doit également être incluse dans la portée de surveillance de Zabbix
Apprentissage recommandé :
Tutoriel vidéo MySQLCe 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!