Dans le cas d'un INNER JOIN ou d'une table à gauche dans un LEFT JOIN, dans de nombreux cas, l'optimiseur trouvera qu'il est préférable d'effectuer tout filtrage en premier (sélectivité la plus élevée) avant d'effectuer réellement n'importe quel type de jointure physique - donc là sont évidemment l'ordre physique des opérations qui sont meilleurs.
Dans une certaine mesure, vous pouvez parfois contrôler cela (ou interférer avec cela) avec votre SQL, par exemple, avec des agrégats dans des sous-requêtes.
L'ordre logique de traitement des contraintes dans la requête ne peut être transformé que selon des transformations invariantes connues.
Donc :
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
est toujours équivalent logiquement à :
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
et ils auront généralement le même plan d'exécution.
D'autre part :
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
n'est PAS équivalent à :
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
et ainsi l'optimiseur ne va pas les transformer en le même plan d'exécution.
L'optimiseur est très intelligent et est capable de déplacer les choses avec assez de succès, y compris de réduire les vues et les fonctions de table en ligne, ainsi que de pousser les choses vers le bas à travers certains types d'agrégats avec assez de succès.
Généralement, lorsque vous écrivez du SQL, il doit être compréhensible, maintenable et correct. En ce qui concerne l'efficacité de l'exécution, si l'optimiseur a du mal à transformer le SQL déclaratif en un plan d'exécution avec des performances acceptables, le code peut parfois être simplifié ou des index ou astuces appropriés ajoutés ou décomposés en étapes qui devraient effectuer plus rapidement - le tout dans des ordres successifs d'envahissement.
