Optimisation de la requête: l'impact dramatique du remplacement des sous-requêtes par des jointures

Une application récente refactoring a considérablement amélioré les performances en remplaçant une sous-requête par une jointure intérieure. Le code d'origine a utilisé une sous-requête dans la clause où :

WHERE id IN (SELECT id FROM ...)

Le changement a entraîné une étonnante accélération de 100x, passant le temps d'exécution de 50 secondes à 0,3 seconde. Cela soulève la question: pourquoi une telle différence massive?

La clé réside dans la compréhension du comportement de sous-requête. Une sous-requête corrélée - où la clause de la sous-requête dépend des valeurs de la requête extérieure - s'exécute à plusieurs reprises pour chaque ligne de la requête extérieure. Cette exécution répétée est extrêmement inefficace. En revanche, une sous-requête non corrélée ne s'exécute qu'une seule fois.

La sous-requête originale a été corrélée. Pour chaque ligne traitée, la base de données devait exécuter la sous-requête, conduisant à de nombreuses recherches.

Le remplacement de la sous-requête par une jointure intérieure a permis à la base de données de tirer parti des recherches d'index efficacement. La condition de jointure (par exemple, soumission_id = st_tag_id ) a autorisé une seule recherche indexée par ligne de qualification. Cela a considérablement réduit les accès de la base de données, expliquant le saut de performances.

la leçon? Un examen attentif des sous-questionnaires en fonction des jointures est vital pour l'optimisation des requêtes SQL. Comprendre les sous-requêtes corrélées et non corrélées, et leurs implications de performance, permet aux développeurs d'écrire des requêtes de base de données beaucoup plus rapides et plus efficaces.