Maison > base de données > tutoriel mysql > Sous-requêtes et jointures : quand une jointure offre-t-elle une amélioration des performances 100 fois ?

Sous-requêtes et jointures : quand une jointure offre-t-elle une amélioration des performances 100 fois ?

Mary-Kate Olsen
Libérer: 2025-01-17 16:53:13
original
462 Les gens l'ont consulté

Subqueries vs. Joins: When Does a Join Offer a 100x Performance Boost?

Sous-requêtes et jointures : l'optimisation des performances révélée

Une récente mise à niveau de l'application a considérablement amélioré les performances (vitesse multipliée par 100) en remplaçant les sous-requêtes par des jointures. Cela met en évidence les différences d’efficacité significatives entre ces techniques SQL. Le code d'origine utilisait une sous-requête dans la clause WHERE ; la version optimisée utilisait une jointure interne. Examinons pourquoi cela a fait une telle différence.

Comprendre l'écart de performances

Le problème principal réside dans la façon dont SQL gère les sous-requêtes corrélées, celles dont la clause WHERE dépend des données de la requête externe. Une sous-requête corrélée s'exécute à plusieurs reprises, une fois pour chaque ligne de la requête externe, ce qui entraîne une surcharge importante. Les sous-requêtes non corrélées, avec des clauses WHERE indépendantes, ne s'exécutent qu'une seule fois.

Analyse du plan d'exécution

L'analyse des plans d'exécution révèle le goulot d'étranglement des performances. La sous-requête d'origine :

<code class="language-sql">WHERE id IN (SELECT id FROM ...)</code>
Copier après la connexion

a démontré un temps d'exécution de 4 secondes par ligne pour la sous-requête corrélée :

<code>2 DEPENDENT SUBQUERY submission_tags ref st_tag_id st_tag_id 4 const 2966 Using where</code>
Copier après la connexion

La jointure interne refactorisée a cependant montré un temps d'exécution considérablement amélioré :

<code class="language-sql">eq_ref PRIMARY PRIMARY 4 newsladder_production.st.submission_id 1 Using index</code>
Copier après la connexion

Le temps de traitement a été réduit à 1 seconde par ligne indexée.

Clé à retenir

L'amélioration des performances 100x provient de l'élimination de la sous-requête corrélée coûteuse. La jointure interne a permis au moteur SQL d'optimiser l'exécution des requêtes, réduisant ainsi considérablement le temps de traitement.

Considération importante

Comprendre la différence entre les sous-requêtes corrélées et non corrélées est essentiel pour l'optimisation des bases de données. L'utilisation d'outils d'analyse de plan de requête aide les développeurs à identifier les goulots d'étranglement en matière de performances et à mettre en œuvre des solutions efficaces.

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!

source:php.cn
Déclaration de ce site Web
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
Derniers articles par auteur
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal