Je voudrais confirmer que la requête SQL
SELECT ....
FROM bananas,
apples,
oranges
LEFT JOIN kiwis ON kiwis.orange_id = oranges.id
WHERE ....
3 Réponses :
J'ai fait SQL pour des années d'ânes et de toutes mes expériences, l'ordre de la table n'a pas d'importance. La base de données examinera la requête dans son ensemble et créera le plan de requête optimal. C'est pourquoi les entreprises de base de données emploient de nombreuses personnes atteintes de doctorat dans des optimisations de plan de requête.
Le fournisseur de base de données commettrait un suicide commercial s'il optimisait par l'ordre dans lequel vous avez personnellement répertorié le SQL dans votre requête.
Les versions plus anciennes de la SGBD l'ont fait de cette façon (par exemple, 7 & 8). Ceci était généralement appelé "optimiseur basé sur des règles" lorsqu'il examine statiquement la requête et appliqua certaines règles en fonction de la structure de la requête pour déterminer le plan d'exécution. Avec un optimiseur basé sur des règles, la première table était généralement la table de conduite et la commande avait donc une influence majeure sur la performance.
C'est pareil mais il est ambigu comme l'enfer avec les em> implicites em> jointures croisées. Utilisez des jointures explicites.
Si vous vous joignez à la clause O quelle que soit les résultats mai em> diffèrent car des jointures et des filtres sont mélangés. P> SELECT ....
FROM apples a
JOIN
bananas b ON ...
JOIN
oranges o ON ...
LEFT JOIN
kiwis k ON k.orange_id = o.id
WHERE (filters only)
Une très bonne et approfondie de réponse, merci. Pour l'enregistrement, oui, les conditions de jointure sont dans la clause WHERE. Il s'agit d'une application héritée et je suis en train de refactons certaines des questions.
L'avez-vous testé? L'ordre de
rejoindre S est hors de propos, sauf si vous avez besoin de résultats spécifiques de précédentjoindre sLes bananes, les pommes, les oranges sont-elles un produit cartésien? Ou la clause "Rejoindre-in-where"?
Explique vous montrera: postgreSQL.org/docs/current/static/sql -Explain.html et il n'y a aucune raison pour tout indice du tout, PostgreSQL est assez intelligent.