Résumer et trier les pièges de la requête de jointure à gauche MySQL qui est lente et prend beaucoup de temps

Cet article vous apporte des connaissances pertinentes sur mysql Il présente principalement les pièges des requêtes de jointure gauche qui sont lentes et longues, y compris la commande EXPLAIN pour analyser l'instruction SELECT. Jetons-y un coup d'œil ensemble, j'espère. Utile à tout le monde.

Apprentissage recommandé : Tutoriel vidéo MySQL

Contexte du problème

Deux tables, l'une est la table utilisateur a (la clé primaire est de type int) et l'autre est la table d'informations spécifiques à l'utilisateur b (l'identifiant de la table utilisateur le champ est de type varchar).

Parce que nous souhaitons afficher les utilisateurs et les informations sur les utilisateurs, nous devons interroger en conséquence. Cependant, nous avons constaté que la requête après la jointure gauche est lente et prend trop de temps. Les données de la table utilisateur sont d'environ 20 000.

Analyse et traitement des problèmes

1. La commande EXPLAIN analyse l'instruction SELECT

Le champ de type fournit une base importante pour juger si la requête est efficace. Grâce au champ de type, nous jugeons que cette requête. est une analyse de table complète ou une analyse d'index, etc.

TOUS : indique une analyse de table complète. Ce type de requête est l'une des requêtes les moins performantes.

De manière générale, nos requêtes ne devraient pas avoir TOUS les types de requêtes, car de telles requêtes. are Lorsque la quantité de données est importante, ce sera un énorme désastre pour les performances de la base de données. Si une requête est de type ALL, d'une manière générale, elle peut être évitée en ajoutant un index au champ correspondant

2. .Nouvel index

Car la table de découverte Le champ b n'a pas été indexé auparavant.

alter table a add index idx_mbrID (mbrID);

Expliquez à nouveau l'analyse

et constatez que le type a changé en réf. En fonction de la relation de performance des différents types de types (

ALL < index < range ~ index_merge < ref < eq_ref < const < system

), cela semble OK après comparaison, donc la requête est exécutée.

3. Modifier le type de champ d'index pour qu'il soit cohérent

Après avoir exécuté la requête, j'ai constaté que la vitesse d'exécution n'était pas optimisée. J'ai soigneusement regardé le tableau conçu par mon précédent collègue et j'ai constaté que le champ de type d'index. était incohérent, je l'ai donc changé en varchar en int et j'ai à nouveau interrogé pour trouver la vitesse de requête.

Même si la chaîne écrite dans le code Java a été modifiée en int dans la base de données, le test actuel peut être utilisé normalement

Résumé

Après avoir résolu le problème, j'ai ouvert le manuel de développement et j'ai constaté que la spécification de l'index force clairement les types de données à être cohérents lors des jointures, le champ associé doit avoir un index ! ! !

Apprentissage recommandé : Tutoriel vidéo MySQL

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!