Ne paniquez pas quand quelque chose se produit, enregistrez-le d'abord : mysql en optimisation lente des requêtes

Cet article vous présente le problème de l'optimisation lente des requêtes MySQL. Je vais vous guider étape par étape pour analyser SQL, vérifier et optimiser. J'espère qu'il vous sera utile.

Souvenez-vous d'une optimisation lente des requêtes MySQL - une démonstration en direct de la liste de tâches de l'environnement de production a pris 5 à 6 secondes pour charger les résultats, le visage du chef de produit ne pouvait pas le supporter ; vieux développeur avec de nombreuses années d'expérience, pensa-t-il. Bon sang, tu gifle.

Cependant, avec de nombreuses années d’expérience dans le monde des arts martiaux, ne paniquez pas lorsque des choses arrivent et prenez d’abord une photo.

Apprentissage recommandé : "Tutoriel vidéo MySQL"

La première étape, analyser SQL

 ***from event i 
 left join project p on i.project_id = p.project_code 
 left join dict d on i.type_id = d.id 
 left join record re on re.incident_id = i.id
 left join type it on it.id = i.type_id 
 where i.version_flag = 0 and i.flow_id in (大量条件)***复制代码

Lorsque flow_id in est connecté à un grand nombre de conditions, SQL ralentit directement, des 80 ms précédentes à 5,8 secondes. De plus, ici, il existe de nombreuses tables associées.

La deuxième étape consiste à vérifier l'index et à exécuter expliquer

Lorsque nous vérifions l'index et constatons que re.incident_id et i.flow_id ne sont pas indexés, nous sommes donc ravis. Le problème est trouvé et l'index est. construits cependant, lorsque nous exécutons SQL, nous constatons qu'ils ne sont pas indexés ! Aussi intelligent que je sois, j'ai ouvert expliquer directement et j'ai découvert que le type d'enregistrement est tout, ce qui signifie qu'il n'y a pas d'index.

pourquoi?pourquoi?

La troisième étape consiste à vérifier si le type de champ, la longueur et le type de caractère des deux champs liés sont cohérents

Lors de la comparaison du type de champ et de la longueur du champ, on constate qu'ils sont complètement cohérent. Après une courte période de dépression, j'ai découvert quelque chose de nouveau. L'indice - le type de caractère de l'identifiant de la table

event est :

Le type de caractère de l'incident_id de la table d'enregistrement est :

Utilisez utf8mb4 de manière décisive et uniforme pour maintenir l'unité avec l'équipe du projet ; expliquez à nouveau, cela prend un moment Aussi bas qu'une seconde, à la main.

La quatrième étape consiste à forcer l'utilisation des opérations d'index.

mysql effectuera une recherche en texte intégral par défaut si la base d'index d'une table est trop petite. Par conséquent, le volume d'activité de la table est trop important, mais les champs d'index sont fondamentalement les mêmes. Dans le cas de data ou null, vous devez toujours écrire l'index forcé dans sql ; utilisez la solution d'index forcé dans sql et ajoutez l'index forcé (alarm_id) après la jointure gauche -

La cinquième étape, IN est généralement d'y aller. L'index

n'effectue une analyse complète de la table que lorsque les données derrière l'IN correspondent à plus de 30%

dans la table de données sans utiliser l'index. Par conséquent, que ce soit l'IN. L'utilisation de l'index est liée à la quantité de données qu'il contient. Une grande quantité de données peut être traitée à l'aide de la jointure gauche.

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!